On Dec 27, 2014, at 9:56 AM, Segher Boessenkool
wrote:
> From gcc.dg/ubsan/ubsan.exp:
>
> # Main loop.
> if [check_effective_target_fsanitize_undefined] {
> That only runs once, doesn't it?
Yes, it does. Perfect.
Hi Michael and Jan-Benedict,
On Fri, 19 Dec 2014 13:56:50, Michael Haubenwallner wrote:
> On the way to prepare some (aix) libtool patch for toplevel libtool.m4
> I've discovered that different versions of automake were used to generate
> files across various libs:
>
> most libs: automa
Greetings,
I would like peoples opinion of adding another column to the tables
indicating C++ feature status for C++11 and C++14 that contains the
relevant SD-6 feature macro.
Ed
Index: htdocs/projects/cxx0x.html
===
RCS file: /
On 12/27/2014 11:49 AM, Momchil Velikov wrote:
struct C {
C(const C &);
};
struct X {
operator C() const;
};
C a{X()};
The variable "a" is initialised by direct list-initialization
according to 8.5.4. [dcl.init.list] #3 and 13.3.1.7 [over.match.list].
As the class C does not have
On 12/27/2014 04:38 PM, Momchil Velikov wrote:
+ else if (t != x && t != error_mark_node)
+ {
+ /* This is a non-friend re-declaration of a possibly
+hidden function or a function template, so don't hide
+it. */
+ DECL_ANTI
std::uninitialized_copy tries to test assignability as follows:
is_assignable<_ValueType1, _RefType>::value
This is the wrong way around. For example, when the iterators are char*, this
ends up as
is_assignable::value
which is false. It should be
is_assignable::value
which is tr
and regtested again on top of:
Target: x86_64-unknown-linux-gnu
Configured with: /home/chill/src/gcc-friend-define/configure
--prefix=/home/chill/opt/gcc-friend-define --enable-languages=c,c++
--disable-multilib
Thread model: posix
gcc version 5.0.0 20141227 (experimental) (GCC)
diff --git a
> OK for trunk? What about the other open branches?
OK for trunk.
After it’s been in for a bit of time, probably OK for all active branches,
unless someone (or you) think it’s unwise.
FX
Hi,
On 12/27/2014 05:49 PM, Momchil Velikov wrote:
+conversion in the context of list-initialisation. */
Nit: I think you want to spell initialization, with a z, like in the
standard (and all the uses of the expression in our front-end)
Paolo.
On Sat, Dec 27, 2014 at 09:34:44AM -0800, Mike Stump wrote:
> >>> Please consider pulling the check out and putting it in at the top of the
> >>> ubsan.exp type of files.
> >>>
> >>> I suspect there is little need to check this more than once per language
> >>> or so.
> >
> > Actually, that is
Hi all,
here is a small patch for an F08 extension: Allocatable components
don't have to be specified in structure constructors any more.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-12-27 Janus Weil
PR fortran/60357
* array.c (check_constructor): Ignore
On Dec 27, 2014, at 8:33 AM, Segher Boessenkool
wrote:
> On Sat, Dec 27, 2014 at 10:11:59AM -0600, Segher Boessenkool wrote:
>>> Please consider pulling the check out and putting it in at the top of the
>>> ubsan.exp type of files.
>>>
>>> I suspect there is little need to check this more than
On Sat, Dec 27, 2014 at 8:18 AM, Mike Stump wrote:
> On Dec 26, 2014, at 7:57 AM, "H.J. Lu" wrote:
>> On Thu, Dec 25, 2014 at 9:07 PM, Gerald Pfeifer wrote:
>>> On Thursday 2014-12-18 11:35, H.J. Lu wrote:
Updated.
>>>
>>> "the RAX register" (i.e., add "the"), and I suggest to make
>>> this
Hello,
This patch fixes an issue with C++11 where user-defined conversion is
not properly suppressed in certain cases of list-initialisation.
Consider the example:
--- 8< --
struct C {
C(const C &);
};
struct X {
operator C() const;
};
C a{X()};
--- 8< --
This program i
On Sat, Dec 27, 2014 at 10:11:59AM -0600, Segher Boessenkool wrote:
> > Please consider pulling the check out and putting it in at the top of the
> > ubsan.exp type of files.
> >
> > I suspect there is little need to check this more than once per language or
> > so.
Actually, that is already ho
On Sat, Dec 27, 2014 at 08:09:47AM -0800, Mike Stump wrote:
> > I normally build with --disable-libsanitizer, because the sanitizers
> > testresults are very unreproducable, so just annoying noise. This however
> > makes most (all?) ubsan testcases fail, since they want to load a shared
> > librar
On Dec 26, 2014, at 7:57 AM, "H.J. Lu" wrote:
> On Thu, Dec 25, 2014 at 9:07 PM, Gerald Pfeifer wrote:
>> On Thursday 2014-12-18 11:35, H.J. Lu wrote:
>>> Updated.
>>
>> "the RAX register" (i.e., add "the"), and I suggest to make
>> this a sentence, similar to my previous mail for the other
>> u
On Dec 24, 2014, at 3:21 PM, Segher Boessenkool
wrote:
> I normally build with --disable-libsanitizer, because the sanitizers
> testresults are very unreproducable, so just annoying noise. This however
> makes most (all?) ubsan testcases fail, since they want to load a shared
> library that does
On Dec 27, 2014, at 3:07 AM, Gerald Pfeifer wrote:
>> New Languages and Language specific
>> improvements + + > href="http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf";> OpenMP 4.0
>> + specification offloading features are now supported in C/C++ and
>> + Fortran compiler +
>
> "supported
I'm checking in the attached patch to switch ldo/sto offsets to 16 bits
from 32. This was a long overdue backwards incompatible change to the
ISA.
2014-12-27 Anthony Green
* config/moxie/moxie-protos.h (moxie_offset_address_p): Define.
* config/moxie/constraints.md (B): Repl
Hi,
sreal::shift does have wrong bounds on exponent shift (that was copied over
from shift_right).
Bootstrapped/regtested x86_64-linux, comitted as obvious.
Honza
* sreal.h (sreal::shift): Fix sanity check.
Index: sreal.h
=
Hello!
unpckhps and punpckhpd are not correct insns to move 32bit X[1] to
X[0] in XMM registers. These two insns move X[2] to X[0]. The patch
uses movshdup, pshufd and shufps instead.
This problem however is a non-issue since MMX moves are never
generated, but insn pattern should be fixed neverth
Hi Kirill,
On Friday 2014-12-12 14:43, Kirill Yukhin wrote:
> These change adds mention of OpenMP4 offloading support in GCC: in
> release notes and in news section of main page.
good you thought of that, thank you!
> Index: htdocs/index.html
> ==
On Friday 2014-12-19 10:24, Kyrill Tkachov wrote:
>>> https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00947.html
>> This patch almost certainly falls under the obvious rule:
> Yeah, one could almost make an argument that it's a typo fix.
> Committed as r218897.
I am not a big fan of stretching the c
On Fri, Dec 26, 2014 at 9:52 PM, Andi Kleen wrote:
> Uros Bizjak writes:
>
>> Hello!
>>
>> This patch uses x{v,}asprintf where the result of the function is unused.
>
> I would be careful with it. Some old glibc versions have an asprintf
> that corrupts memory. If you do this force the libiberty
On Fri, Dec 26, 2014 at 7:38 PM, H.J. Lu wrote:
> There is no counter part of x32 in MS ABI. Issue an error when ms_abi
> attribute is used with x32. OK for trunk and branches?
Is there a fundamental reason that x32 doesn't support ms_abi? IIRC,
x32 uses x86_64 ABI, so I see no reason why ms_a
26 matches
Mail list logo
