On 03/28/2016 01:56 PM, Florian Weimer wrote:
In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though
he provides the "-Werror=return-type" option, the compiler doesn't
flag the warning/error about a control reaching the end of a non-void
function, due to the presence of the "-w" opt
> In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though
> he provides the "-Werror=return-type" option, the compiler doesn't
> flag the warning/error about a control reaching the end of a non-void
> function, due to the presence of the "-w" option. He points out that
> clang++ wtill
On March 28, 2016 7:23:26 PM GMT+02:00, Cristina Georgiana Opriceana
wrote:
>Hello,
>
>In order to compute all the statements where a variable is used, is it
>enough to rely on the SSA analysis? I tried to do something like this:
>
>FOR_EACH_LOCAL_DECL (cfun, i, var) {
>for (unsigned int
In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though he
provides the "-Werror=return-type" option, the compiler doesn't flag the
warning/error about a control reaching the end of a non-void function, due to
the presence of the "-w" option. He points out that clang++ wtill flags
Hello,
In order to compute all the statements where a variable is used, is it
enough to rely on the SSA analysis? I tried to do something like this:
FOR_EACH_LOCAL_DECL (cfun, i, var) {
for (unsigned int i = 0; i < num_ssa_names; i++) {
if (ssa_name(i) && SSA_NAME_VAR (ssa_nam
* Paul Koning:
>> On Mar 28, 2016, at 8:11 AM, Florian Weimer wrote:
>>
>> ...
>> The problem is that “reading” is either not defined, or the existing
>> flatly contradicts existing practice.
>>
>> For example, if p is a pointer to a struct, will the expression &p->m
>> read *p?
>
> Presumably
> On Mar 28, 2016, at 8:11 AM, Florian Weimer wrote:
>
> ...
> The problem is that “reading” is either not defined, or the existing
> flatly contradicts existing practice.
>
> For example, if p is a pointer to a struct, will the expression &p->m
> read *p?
Presumably the offset of m is substan
The attached shell script will generate a larger version
of the following:
constexpr bool static_str_equal(const char* x, const char* y) {
return (*x == 0 || *y == 0) ?
(*x == *y) :
((*x == *y) && static_str_equal(x + 1, y + 1));
}
int main(void)
{
static_assert( !static_str_equal("uns
* Andrew Haley:
> "volatile" doesn't really mean very much, formally speaking. Sure, the
> standard says "accesses to volatile objects are evaluated
> strictly according to the rules of the abstract machine," but nowhere
> is it specified exactly what constitutes an access.
Reading or modifying
On 27/03/16 06:57, Michael Clark wrote:
> GCC, Clang folk, any ideas on why there is a stack spill for a
> volatile register argument passed in esi? Does volatile force the
> argument to have storage allocated on the stack? Is this a corner
> case in the C standard? This argument in the x86_64 cal
On Mon, 28 Mar 2016, Allan Sandfeld Jensen wrote:
On Sunday 27 March 2016, Marc Glisse wrote:
On Sun, 27 Mar 2016, Allan Sandfeld Jensen wrote:
Would it be possible to add constexpr to the intrinsics headers?
For instance _mm_set_XX and _mm_setzero intrinsics.
Already suggested here:
https:
11 matches
Mail list logo
