On Wed, 7 Jun 2017 17:18:49 -0600
Jeff Law wrote:
> On 06/07/2017 02:25 PM, Antonio Diaz Diaz wrote:
> > Dear GCC steering committee,
> >
> > This has been recently asked in this list[1], but in case you have
> > missed it because of a subject line not explicit enough, I would
> > like to appeal
Matthias Klose wrote:
I'm not commenting on the "inadequateness" of xz, but maybe it would
better help lzip to address some project issues and promoting it as
an alternative rather than appealing to the GCC steering committee.
It is not my intention to "help lzip", but to use lzip as a mean to
On Wed, 7 Jun 2017 15:25:26 -0700
Matthias Klose wrote:
> On 07.06.2017 13:25, Antonio Diaz Diaz wrote:
> > Dear GCC steering committee,
> >
> > This has been recently asked in this list[1], but in case you have
> > missed it because of a subject line not explicit enough, I would
> > like to app
On 06/07/2017 02:25 PM, Antonio Diaz Diaz wrote:
> Dear GCC steering committee,
>
> This has been recently asked in this list[1], but in case you have
> missed it because of a subject line not explicit enough, I would like to
> appeal to you directly.
>
> [1] http://gcc.gnu.org/ml/gcc/2017-06/msg
Snapshot gcc-6-20170607 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/6-20170607/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6
On 07.06.2017 13:25, Antonio Diaz Diaz wrote:
> Dear GCC steering committee,
>
> This has been recently asked in this list[1], but in case you have missed it
> because of a subject line not explicit enough, I would like to appeal to you
> directly.
>
> [1] http://gcc.gnu.org/ml/gcc/2017-06/msg000
On 06/07/2017 01:31 PM, Florian Weimer wrote:
With lazy binding, the constructors of libraries should run in graph
dependency order, which means this constructor should run before any
users.
Except when another shared object uses the function from its own ELF
constructor, and the libatomic cons
* Richard Henderson:
> On 06/05/2017 10:50 PM, Florian Weimer wrote:
>> * Steve Ellcey:
>>
>>> I have a question about the use of IFUNCs in libatomic. I was looking at
>>> the
>>> arm implementation and in gcc/libatomic/config/linux/arm/host-config.h I
>>> see:
>>>
>>> extern bool libat_ha
Dear GCC steering committee,
This has been recently asked in this list[1], but in case you have
missed it because of a subject line not explicit enough, I would like to
appeal to you directly.
[1] http://gcc.gnu.org/ml/gcc/2017-06/msg9.html
Since 2017-05-24 weekly snapshots use xz compre
On Wed, 2017-06-07 at 12:21 -0700, Richard Henderson wrote:
> > Setting the variable in the constructor wouldn't influence IFUNC
> > resolver behavior because those can run before ELF constructors
> > (even with lazy binding).
> With lazy binding, the constructors of libraries should run in graph
On 06/05/2017 10:50 PM, Florian Weimer wrote:
* Steve Ellcey:
I have a question about the use of IFUNCs in libatomic. I was looking at the
arm implementation and in gcc/libatomic/config/linux/arm/host-config.h I see:
extern bool libat_have_strexbhd HIDDEN;
# define IFUNC_COND_
On 06/06/2017 09:01 AM, Steve Ellcey wrote:
So the question remains, where is libat_have_strexbhd set? As near as
I can tell it isn't set, which would make the libatomic IFUNC pointless
on arm.
libat_have_strexbhd isn't set anywhere. It looks like this was a
prototype that was never fully fl
On Wed, Jun 07, 2017 at 05:16:44PM +0300, K wrote:
> > ui16 *ptr = (ui16*)buf;
> >
> > There's no need for any of this messing about with pointer casts, as has
> > been explained.
> >
>
> Sorry, but I still can't get the idea. Cast from udp_pseudo to uint8_t
> doesn't have an aliasing
On 06/07/2017 04:56 PM, Andrew Haley wrote:
On 07/06/17 14:45, K wrote:
And I found that that a version which I beleve mustn't have aliasing
problems still generates same warnings.
It still has aliasing problems: you can't make them magically go away
by using an intermediate uint8_t*.
You're
On 07/06/17 14:45, K wrote:
> And I found that that a version which I beleve mustn't have aliasing
> problems still generates same warnings.
It still has aliasing problems: you can't make them magically go away
by using an intermediate uint8_t*.
You're doing this:
struct udp_pseudo {
That snippet invokes undefined behavior at runtime (violates C++ aliasing
rules),
so just fix it, rather than bother with bugreports. E.g. look for
-fstrict-aliasing
in GCC documentation, or read the C++ standard. With -fno-strict-aliasing,
which is a workaround for broken code you won't ge
Hi all,
I'm using a gcc plugin to do some instrument during compilation.
Instrument in functions is simple. But how can I create new functions,
and append it to executables? I want to instrument in this way: to
create new functions, add my codes into them, then instrument some
calls to them.
fo
On 07/06/17 11:33, Andrew Haley wrote:
> On 07/06/17 10:15, Kirill Yu Berezin wrote:
>> My question is. Is this an expected behaviour or I must report a bug ?
>
> It's not a bug: your code displays undefined behaviour: you're casting
> a pointer to struct udp_pseudo fields to an array of uint16_t.
On 07/06/17 10:15, Kirill Yu Berezin wrote:
> My question is. Is this an expected behaviour or I must report a bug ?
It's not a bug: your code displays undefined behaviour: you're casting
a pointer to struct udp_pseudo fields to an array of uint16_t. This
is never well-defined in C++, but if you
On Wed, Jun 07, 2017 at 12:15:54PM +0300, Kirill Yu Berezin wrote:
> Hello!
>
> I have a code snippet (actually it is a part of larger project):
That snippet invokes undefined behavior at runtime (violates C++ aliasing
rules),
so just fix it, rather than bother with bugreports. E.g. look for
-
Hello!
I have a code snippet (actually it is a part of larger project):
#include
#define UDP_PROTO_NUMBER 17
uint32_t calc_16bit_checksum_part(uint8_t* buf, int len, uint32_t ret) {
uint16_t *ptr = reinterpret_cast(buf);
int i;
for( i = 0; i < (len / 2); ++i) {
On 7 June 2017 at 08:38, 林作健 wrote:
> I have found the cause of this bug.
> In 5.3, the function strip_typedefs only use
> result = cp_build_type_attribute_variant (result, TYPE_ATTRIBUTES (t));
> but in 6.3 remove_attributes prediction get invovled:
> if (TYPE_ATTRIBUTES (t))
> {
> if
I have found the cause of this bug.
In 5.3, the function strip_typedefs only use
result = cp_build_type_attribute_variant (result, TYPE_ATTRIBUTES (t));
but in 6.3 remove_attributes prediction get invovled:
if (TYPE_ATTRIBUTES (t))
{
if (remove_attributes)
result = apply_identity_attrib
23 matches
Mail list logo
