https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102361
--- Comment #7 from DAC324 ---
Created attachment 51470
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51470=edit
File mm/memcontrol.c saved with -save-temps option (2/2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102361
--- Comment #6 from DAC324 ---
Created attachment 51469
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51469=edit
File mm/memcontrol.c saved with -save-temps option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102283
--- Comment #3 from Patrick Palka ---
(In reply to Giuseppe D'Angelo from comment #2)
> Hi,
>
> Do you think that in my original testcase the call should be rejected as
> ambiguous as well? (It seems "reasonable" to me, but maybe I'm missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102361
--- Comment #5 from DAC324 ---
OK, here we go:
make -f ./scripts/Makefile.build obj=mm/kfence \
\
need-builtin=1 \
need-modorder=1
gcc -Wp,-MMD,mm/.memcontrol.o.d -nostdinc -isystem
/usr/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102361
--- Comment #4 from DAC324 ---
Please let me kindly ask you for instructions on how to do that.
As described in the introduction, I was trying to compile the Linux kernel from
the usual source tarball available on kernel.org.
What I did after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102353
--- Comment #6 from Bill Schmidt ---
Thanks, Tobias! I'm sorry for getting this exactly backwards...
Your patch looks good. I am doing a quick host=target=build bootstrap and will
respond on-list when it'sdone.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102361
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102361
--- Comment #2 from DAC324 ---
Please let me kindly ask you for instructions on how to do that.
As described in the introduction, I was trying to compile the Linux kernel from
the usual source tarball available on kernel.org.
What I did after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102365
--- Comment #2 from Jonathan Wakely ---
See e.g. https://gcc.gnu.org/pipermail/gcc/2021-August/237078.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102365
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2021-09-16
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102365
Bug ID: 102365
Summary: Function attribute docs should have an anchor or id on
each attribute.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #19 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #14)
> As for std::experimental::source_location, could we change ABI of those?
Yes, we don't promise stability between major releases for the experimental
stuff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102364
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102364
Martin Liška changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102364
Martin Liška changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org,
gcc version 12.0.0 20210916 (experimental) [master r12-3577-g275a076f762] (GCC)
[582] %
[582] % gcctk -O0 small.c; a.out
[583] %
[583] % gcctk -O1 small.c
[584] % ./a.out
Aborted
[585] %
[585] % cat small.c
int a, b, *c =
short d;
int main() {
unsigned e = 1;
for (d = 9; d > 8; d +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #18 from Peter Dimov ---
I would use it like this: https://godbolt.org/z/1eqEx6678
#include
struct error_category
{
};
error_category const& system_category();
struct error_code
{
error_code( int v, error_category const&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102362
--- Comment #2 from Thomas Schwinge ---
Here, to emit 'note: [...]' ('-fopt-info-note') if because of certain input
source code characteristics (derived from
'DECL_ATTRIBUTES(current_function_decl)'), certain code transformations
do/don't need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102360
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102360
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:8d6b12b2233dabf3573383a15ccc67fdb925e5b3
commit r12-3578-g8d6b12b2233dabf3573383a15ccc67fdb925e5b3
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102363
Bug ID: 102363
Summary: source_location in await_transform has function_name
referring to internal coroutine funclet rather than
source-level function
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #17 from Jakub Jelinek ---
You'd need a different builtin (so that you know the presence of the builtin
means the new behavior), ideally tell the builtin some way the type it should
construct objects in (as opposed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102362
--- Comment #1 from Richard Biener ---
Why would you call such method from the gate()?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #16 from Peter Dimov ---
(In reply to Jakub Jelinek from comment #14)
> But we haven't done that that way and how would headers know if the
> __builtin_source_location that is available is the old or new one?
The header could do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #15 from Peter Dimov ---
(In reply to Jonathan Wakely from comment #13)
> It wouldn't work correctly in all cases, as Jakub points out, because
> std::source_location::current() is part of the magic.
>
> And I'm not convinced we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #14 from Jakub Jelinek ---
But we haven't done that that way and how would headers know if the
__builtin_source_location that is available is the old or new one?
As for std::experimental::source_location, could we change ABI of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #13 from Jonathan Wakely ---
It wouldn't work correctly in all cases, as Jakub points out, because
std::source_location::current() is part of the magic.
And I'm not convinced we want/need to support those uses.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #12 from Jonathan Wakely ---
We could have added std::__source_location_impl as the type that the built-in
returns and used that instead of making it a private member of
std::source_location. That would also have allowed it to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #11 from Jakub Jelinek ---
That is not possible, because std::source_location::current() should be
consteval and it can't be in C++ < 20, and without consteval it will behave
significantly differently. Note, the C++ FE knows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102361
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102347
--- Comment #3 from Kewen Lin ---
This seems not a target specific issue. I noticed the target_option tree node
is created expectedly when seeing target pragma, it explains why it works well
without lto. When lto does streaming out, it does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #10 from Peter Dimov ---
(In reply to Jakub Jelinek from comment #9)
> That would be an aliasing violation.
> The artificial vars created by __builtin_source_location have the
> std::source_location::__impl type, so accessing those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102362
Bug ID: 102362
Summary: 'dump_printf_loc' doesn't work from 'gate' method of a
'gimple_opt_pass'
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #9 from Jakub Jelinek ---
That would be an aliasing violation.
The artificial vars created by __builtin_source_location have the
std::source_location::__impl type, so accessing those using some other dynamic
type is invalid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #8 from Peter Dimov ---
(In reply to Jakub Jelinek from comment #6)
> Note, having the struct somewhere else isn't that useful unless you know
> exactly how its non-static data members are named and what they mean, so
> ideally a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #7 from Peter Dimov ---
(In reply to Jonathan Wakely from comment #5)
> Sure. It's just a question of whether we're trying to provide a general
> purpose extension available for users, or an internal helper for the
> std::lib. IIRC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60865
Zdenek Sojka changed:
What|Removed |Added
Known to work||5.5.0, 6.5.0, 7.5.0, 8.5.0
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102357
--- Comment #6 from Jonathan Wakely ---
https://github.com/cplusplus/draft/commit/219538a7be4f3e71f05070d1a52aa7150505e732
is the editorial change that resolved CWG 2221, but I don't think it's relevant
here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102357
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102361
Bug ID: 102361
Summary: Errors compiling Linux kernel 5.14.4 with
CONFIG_FORTIFY=y
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81344
Michael Osipov changed:
What|Removed |Added
CC||michael.osipov at siemens dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #6 from Jakub Jelinek ---
Note, having the struct somewhere else isn't that useful unless you know
exactly how its non-static data members are named and what they mean, so
ideally a class with accessor methods, which is what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #5 from Jonathan Wakely ---
Sure. It's just a question of whether we're trying to provide a general purpose
extension available for users, or an internal helper for the std::lib. IIRC we
explicitly decided we only cared about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102359
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102353
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102360
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102356
Martin Liška changed:
What|Removed |Added
Summary|compile-time explosion at |[11/12 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102360
Martin Liška changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102360
Bug ID: 102360
Summary: ICE in can_native_interpret_type_p at
gcc/fold-const.c:8800
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102359
Martin Liška changed:
What|Removed |Added
Priority|P3 |P1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102359
Bug ID: 102359
Summary: ICE gimplification failed since
r12-3433-ga25e0b5e6ac8a77a
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102295
--- Comment #10 from Jakub Jelinek ---
Fixed also for 11.3+.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88578
--- Comment #8 from Jakub Jelinek ---
Fixed for 12.1+ and 11.3+ for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102305
--- Comment #8 from Jakub Jelinek ---
Fixed for 11.3+ now too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080
--- Comment #15 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:a26ff83ed07e33c4aa46f3314553c0d15ca21100
commit r12-3569-ga26ff83ed07e33c4aa46f3314553c0d15ca21100
Author: liuhongt
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102357
--- Comment #4 from jim x ---
I haven't found that pull request. However, the proposal sources from P0641R2,
see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0641r2.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102357
--- Comment #3 from Andrew Pinski ---
So I suspect it is/was DR 2221 :).
Basicallythe editorial changes resolved it.
So yes there is a change between C++17 and C++20.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94302
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-09-16
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102357
--- Comment #2 from jim x ---
This part in c++20 is more clear than c++17, which is added since c++20, see
https://timsong-cpp.github.io/cppwp/n4861/dcl.fct.def.default#2. What the
version I'm testing the code is GCC 12.0 with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78463
--- Comment #2 from Richard Biener ---
There were more instances fixed (like PR70586 was), but there may be still
cases left. Also there's still the missed optimization of
computing/propagating 'notrap'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102357
--- Comment #1 from Andrew Pinski ---
Was there a change to C++ beteween C++17 and C++20 here? A defect report?
Because clang errors out with the same message as GCC for C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102358
Bug ID: 102358
Summary: niter_base and miter_base overloaded for move_iterator
missing constexpr
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101934
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101934
--- Comment #8 from CVS Commits ---
The releases/gcc-11 branch has been updated by Andrew Pinski
:
https://gcc.gnu.org/g:f00530266f89b28e8286cdd2f587e046a27d2193
commit r11-9001-gf00530266f89b28e8286cdd2f587e046a27d2193
Author: Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102356
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Last reconfirmed|
101 - 165 of 165 matches
Mail list logo
