The symbol is exposed to C by dso_handle.h, and since it's a single
8-byte pointer, it is just within the threshold for being in the small
data (or bss) section, so code accessing it will use GP-relative
addressing. Therefore we must put it in .sdata/.sbss in case our other
data sections grow too b
Darwin doesn't have support for -mcmodel={medium, large, kernel} so we don't
expect tests for those things to work.
For now mark them as xfail where possible and skip where that isn't.
These changes will be logged onto the PR and therefore can be backed
out when the facility is implemented.
teste
On Sat, 1 Jun 2019 at 22:40, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> Ok, third time's a charm.
>
> I was brain dead about the constexpr patch.?? I'm now setting a constexpr
> variable from test() in a caller.
Looks good. Jonathan needs to approve it, though.
> But static_assert is a const
On 6/1/19 2:42 PM, Ville Voutilainen wrote:
On Sat, 1 Jun 2019 at 21:09, Ed Smith-Rowland <3dw...@verizon.net> wrote:
On 5/31/19 6:29 PM, Ville Voutilainen wrote:
On Sat, 1 Jun 2019 at 01:24, Ed Smith-Rowland via libstdc++
wrote:
Greetings,
Iterators for and are usabe in a constexpr contex
On Sat, 1 Jun 2019 at 21:09, Ed Smith-Rowland <3dw...@verizon.net> wrote:
>
> On 5/31/19 6:29 PM, Ville Voutilainen wrote:
> > On Sat, 1 Jun 2019 at 01:24, Ed Smith-Rowland via libstdc++
> > wrote:
> >> Greetings,
> >>
> >> Iterators for and are usabe in a constexpr context
> >> since C++2017.
>
On 5/31/19 6:29 PM, Ville Voutilainen wrote:
On Sat, 1 Jun 2019 at 01:24, Ed Smith-Rowland via libstdc++
wrote:
Greetings,
Iterators for and are usabe in a constexpr context
since C++2017.
This just adds a compile test to make sure and check a box for C++20
p0858 - ConstexprIterator require
This adds a new warning, -Wglobal-constructors, that warns whenever a
decl requires a global constructor or destructor. Global destructors are
required whenever a decl with thread_local or global storage is declared
with a type with a nontrivial destructor. Global constructors are required
whenever
Hi,
while looking at the cases disambiguated by access path and not by alias simple
alias set lookup I noticed that there are number of accesses to pointers of
different type which we consider as possible equivalent.
For example
struct a *a;
struct b *b;
is currently considered aliasing with LTO
A patch with a ChangeLog this time is attached.
On 6/1/19 9:53 AM, Martin Sebor wrote:
I spent a bunch of time the other day trying to understand why
the second of the two assignments below to a char array was
apparently not being done by trunk
a[0] = 1;
a[1] = 0;
The optimized GIMPLE du
This patch makes the into-SSA code handle LSM temporary variables
as though they had been assignments to the original variable.
In the end, the easiest place to record the link seemed to be
DECL_ABSTRACT_ORIGIN. These sorts of nameless temporaries shouldn't
otherwise have debug info and so should
I spent a bunch of time the other day trying to understand why
the second of the two assignments below to a char array was
apparently not being done by trunk
a[0] = 1;
a[1] = 0;
The optimized GIMPLE dump simply shows:
MEM[(char *)&a] = 1;
when in the past it showed:
MEM[(char[2] *)&a2
This patch tries to track the debug location of memory variables
that have a target_for_debug_bind (and thus have a type that
satisfies is_gimple_reg_type). For each such variable V:
* "# DEBUG V s=> V" marks the start of V's lifetime
* during V's lifetime, "# DEBUG V => X" records that the valu
This patch adds a new rtx code for capturing a decl's DECL_RTL by
reference rather than by value. When used in a VAR_LOCATION, the
VAR_LOCATION continues to track the decl as it changes over time,
rather than "remembering" the value that the decl had at the point
of the VAR_LOCATION.
2019-06-01
Taking the address of a variable stops us doing var-tracking on it,
so that we just use the DECL_RTL instead. This can easily cause wrong
debug info for regions of code that would have had correct debug info
if the variable weren't addressable. E.g.:
{
int base;
get_start (&base);
x[i1] =
On 6/1/19 2:41 AM, Marc Glisse wrote:
> Hello,
>
> this is a small short-cut in the common case where the step is 1. This
> avoids having ldist generate a BIT_AND_EXPR that requires VRP to remove,
> then forwprop to clean up, etc, very close to the end of the
> optimization pipeline. Please do che
When libiberty/rust-demangle.c was initially added, its two exports,
rust_is_mangled and rust_demangle_sym, made it to include/demangle.h.
However, these two functions are merely implementation details of
cplus_demangle and rust_demangle, only the latter should be public.
This is becoming a proble
On 31/05/19 17:15 -0700, Thomas Rodgers wrote:
Revising previous version of this patch to pick another missed
uglification.
OK for trunk, thanks.
I also see this one:
include/pstl/parallel_backend_tbb.h:__buffer(std::size_t n) :
_M_allocator(), _M_ptr(_M_allocator.allocate(n)), _M_buf_s
Hi,
while looking for the reason for extra disambiguations in
aliasing_component_refs I have noticed an odd case. We newly disambiguate:
MEM[(Element_t *)_27 + 4B];
s.globalIDDataBase_m;
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x770fb5
Hello,
this is a small short-cut in the common case where the step is 1. This
avoids having ldist generate a BIT_AND_EXPR that requires VRP to remove,
then forwprop to clean up, etc, very close to the end of the optimization
pipeline. Please do check that the test s==1 is the right one.
An a
19 matches
Mail list logo
