This is the final patch. Bootstrapped and regression tested.
The diagnostics part is the same as in
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03416.html, except for
fixing the minor nit in a comment pointed out by Dodji.
I decided that the best testing would be to convert all calls (except
fo
On 03/03/12 08:41, Paul Richard Thomas wrote:
> Dear Tobias,
>
> This is certainly OK for 4.8.
>
> I have a couple of remarks:
> (i) The DTYPE_TYPE_MASK is 0x38 so that we saturated it a long time
> since! At the moment it does not cause any problems because of the
> extremely limited use of the
On Mon, Dec 01, 2014 at 10:39:58AM -0700, Jeff Law wrote:
> Also OK with a testcase. I'd recommend just using the one from 52714,
> make it m68k specific. Not sure if it's best to scan the assembly or
> .combine dump -- your call.
Here is the testcase. I cannot actually test it on an m68k bui
On Tuesday 2014-12-02 01:51, Jonathan Wakely wrote:
Tested x86_64-linux + powerpc64-linux, committed to trunk.
commit 4701f811a8364bbd009571f5ec6bd562f5433efa
Author: Jonathan Wakely
Date: Mon Oct 20 12:23:24 2014 +0100
Define *_at_thread_exit() functions.
This breaks FreeBSD (bot
On 3 December 2014 at 01:12, Gerald Pfeifer wrote:
> On Tuesday 2014-12-02 01:51, Jonathan Wakely wrote:
>>
>> Tested x86_64-linux + powerpc64-linux, committed to trunk.
>
>
>> commit 4701f811a8364bbd009571f5ec6bd562f5433efa
>> Author: Jonathan Wakely
>> Date: Mon Oct 20 12:23:24 2014 +0100
>>
On 03/12/14 02:12 +0100, Gerald Pfeifer wrote:
This breaks FreeBSD (both 8 and 10) from what I can tell.
[...]
: error: 'atexit' is not a member of 'std'
std::atexit (run);
^
I've just committed this at r218300 which I hope will fix it.
Sorry for the breakage.
commit e256537afe817f0
On 2014-12-01 12:24 PM, Renlin Li wrote:
On 01/12/14 15:58, H.J. Lu wrote:
On Thu, Nov 27, 2014 at 8:38 AM, Renlin Li wrote:
On 27/11/14 15:37, H.J. Lu wrote:
On Thu, Nov 27, 2014 at 7:32 AM, Renlin Li wrote:
On 26/11/14 18:12, H.J. Lu wrote:
On Wed, Nov 26, 2014 at 10:09 AM, Renlin Li
wr
On Tue, Dec 02, 2014 at 07:11:04PM -0600, Segher Boessenkool wrote:
> Here is the testcase. I cannot actually test it on an m68k build, should
> really do something about that (I build lots of cross compilers but they
> cannot run the testsuite). Does it look okay, can you test it yourself?
> [I
On 12/02/2014 08:56 PM, Dmitry Vyukov wrote:
> Hi,
>
> The following patch adds support for instrumentation of globals for
> Linux kernel (-fsanitize=kernel-address). Kernel only supports
> constructors with default priority, but the rest works fine.
>
> OK for trunk?
>
I know this is too late
On 12/02/14 18:11, Segher Boessenkool wrote:
On Mon, Dec 01, 2014 at 10:39:58AM -0700, Jeff Law wrote:
Also OK with a testcase. I'd recommend just using the one from 52714,
make it m68k specific. Not sure if it's best to scan the assembly or
.combine dump -- your call.
Here is the testcase.
Hello,
Manuel López-Ibáñez wrote:
This is the final patch. Bootstrapped and regression tested.
The diagnostics part is the same as in
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03416.html, except for
fixing the minor nit in a comment pointed out by Dodji.
I decided that the best testing wou
On Tue, Dec 02, 2014 at 12:40:12AM +0100, Manuel López-Ibáñez wrote:
> 2014-12-02 Manuel López-Ibáñez
>
> * diagnostic.c (diagnostic_color_init): New.
> * diagnostic.h: Declare.
> * gcc.c (driver::global_initializations): Use it.
> (driver_handle_option): Handle -fdiagnostics-co
101 - 112 of 112 matches
Mail list logo