https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92597
--- Comment #16 from Klaus Leppkes ---
So after reading a bit more, from my understanding, +g should be used for all
integral/floating point/vector types and +m for other (aggregate types) which
cannot end up in an register.
Still, it might be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92597
--- Comment #15 from Klaus Leppkes ---
(In reply to Jakub Jelinek from comment #14)
> By all types I really meant integral/floating point/vector types, you are
> clearing using it with aggregates, those can live just in memory and so
> should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92597
--- Comment #13 from Klaus Leppkes ---
(In reply to Andrew Pinski from comment #11)
> (In reply to Klaus Leppkes from comment #9)
> >
> > g++ -c error_large_lvalue.cpp
> > error_large_lvalue.cpp: In function ‘void DoNotOptimize(Tp&) [with Tp =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92597
--- Comment #12 from Klaus Leppkes ---
"I said "+g", not "+g,r". g stands for general operand, so it allows a
non-immediate operand, whether it is in memory or register."
error_large_lvalue.cpp: In function ‘void DoNotOptimize(Tp&) [with Tp =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92597
--- Comment #9 from Klaus Leppkes ---
Created attachment 47358
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47358=edit
Problem with g instead of m example
g++ -c error_large_lvalue.cpp
error_large_lvalue.cpp: In function ‘void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92597
--- Comment #7 from Klaus Leppkes ---
1.) According to Jacob, g++ gives warning: ("Whether this PR is valid or
invalid is unclear, matching constraints for "m" are unsupported, we even warn
on "=m" (...) : "0" (...) which is the reason why "+m"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92597
--- Comment #6 from Klaus Leppkes ---
As it might be purely related to google benchmark, I opened an issues for
google benchmark citing this bug report:
https://github.com/google/benchmark/issues/903
I search for some doc and found
"g" : Any
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: leppkes at stce dot rwth-aachen.de
Target Milestone: ---
Created attachment 47307
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47307=edit
tiny example with makefile to reprod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89727
--- Comment #2 from Klaus Leppkes ---
So from Richard Biener's post
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89727#c1), it looks like
_ZTWN1B1aE
[
$>c++filt "_ZTWN1B1aE"
TLS wrapper function for B::a
]
is the correct accessor (which
++
Assignee: unassigned at gcc dot gnu.org
Reporter: leppkes at stce dot rwth-aachen.de
Target Milestone: ---
Created attachment 45972
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45972=edit
minimal example of incorrect behavior (static member B::a should be initialized
bef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50932
Bug #: 50932
Summary: inserting a gimple_call with gsi_insert_after creates
error in remove_unreachable_handler
Classification: Unclassified
Product: gcc
Version: 4.5.2
11 matches
Mail list logo
