On 07/04/15 14:14 +0100, Jonathan Wakely wrote:
On 03/04/15 12:13 -0700, Richard Henderson wrote:
On 04/03/2015 07:13 AM, Jonathan Wakely wrote:
+++ b/libstdc++-v3/include/std/atomic
@@ -165,9 +165,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
struct atomic
{
private:
- // Align 1/2/4/
The following makes the checks whether the context allows a PCH file
(only the first include may be one, and not nested) more robust
thereby fixing PR65550.
Bootstrapped and tested on x86_64-unknown-linux-gnu - ok?
Thanks,
Richard.
2015-04-09 Richard Biener
PR pch/65550
* fi
On Thu, Apr 9, 2015 at 2:41 PM, Segher Boessenkool wrote:
> It would be nice if there would be some cc0 target in the compile farm,
> since cc0 isn't going away any time soon :-(
In this case it would be enough to replace the "#ifndef/#ifdef
HAVE_cc0" code with "if (HAVE_cc0)".
That's the simples
Hi,
This patch adds a zero length check into memmove wrapper (also affecting memcpy
and mempcpy) to avoid unnecessary bounds checks. Tested on on
x86_64-unknown-linux-gnu. Applied to trunk.
Thanks,
Ilya
--
libmpx/
2015-04-09 Ilya Enkovich
* mpxwrap/mpx_wrappers.c (__mpx_wrapper_m
Hello,
Patch in the bottom fixes PR target/65671.
It simply generates vextract32x4 (float form) for double extract.
Bootstrap & regtesting in progress.
I'll check it in if pass and back port to 4.9.x.
Feel free comment.
gcc/
* config/i386/sse.md: Generate vextract32x4 if AVX-512DQ
On 04/09/2015 05:38 AM, Jakub Jelinek wrote:
Or supposedly no change at all, as the attributes would be either in
TYPE_ATTRIBUTES, or on TYPE_DECL, but then it would be covered by
the TYPE_NAME comparison.
Interesting point. So maybe all we need to do here is copy
TYPE_ALIGN/TYPE_USER_ALIGN,
On Thu, Apr 09, 2015 at 06:37:01PM +0400, Kirill Yukhin wrote:
> gcc/
> * config/i386/sse.md: Generate vextract32x4 if AVX-512DQ
Please use
PR target/65671
* config/i386/sse.md (vec_extract_hi_): ...
(both PR line and name of pattern missing).
Jakub
On Thu, Apr 09, 2015 at 10:51:12AM -0400, Jason Merrill wrote:
> On 04/09/2015 05:38 AM, Jakub Jelinek wrote:
> >Or supposedly no change at all, as the attributes would be either in
> >TYPE_ATTRIBUTES, or on TYPE_DECL, but then it would be covered by
> >the TYPE_NAME comparison.
>
> Interesting po
Hi David,
Various tools that operate on source code files will inject markers
into them when an unfixable conflict occurs in a merger.
There appears to be no blessed standard for these conflict markers,
but an ad-hoc convention is for 7 '<' , '=', or '>' characters at
the start of a line, follo
This test was failing at -O due to non-trivial conversion at assignment.
The reason is that gimple_fold_builtin_memory_op created invalid GIMPLE,
because fold_ctor_reference called via fold_const_aggregate_ref was
discarding a cast, so it returned a different type than it got. Fixed by
dropping us
On Thu, Apr 09, 2015 at 03:03:38PM +0200, Richard Biener wrote:
> The following makes the checks whether the context allows a PCH file
> (only the first include may be one, and not nested) more robust
> thereby fixing PR65550.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu - ok?
>
> Than
On Thu, Apr 09, 2015 at 09:57:29PM +0200, Bernhard Reutner-Fischer wrote:
> On 9 April 2015 at 21:41, Jakub Jelinek wrote:
> > On Thu, Apr 09, 2015 at 09:27:34PM +0200, Bernhard Reutner-Fischer wrote:
> >> gcc/ChangeLog:
> >>
> >> 2015-04-08 Bernhard Reutner-Fischer
> >>
> >> PR target/55
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65710
The patch was bootstrapped and tested on x86/x86-64, ppc64, and aarch64.
The patch does not contain the test as it is too big. If it is reduced,
the test can be committed.
Committed as rev. 221956.
I am also submi
On Thu, Apr 09, 2015 at 12:29:06PM +0100, Iain Sandoe wrote:
> It turns out that existing versions of clang (used as bootstrap on later
> Darwin editions) support -mdynamic-no-pic, but not the inverse. The patch
> below revises mh-darwin so that it only adds -mdynamic-no-pic when the
> inverse
On Thu, Apr 09, 2015 at 10:48:29AM -0400, Jason Merrill wrote:
> So the first hunk of the first patch is OK.
Ok, I've committed this to fix the regression.
2015-04-09 Jakub Jelinek
PR c++/65690
* tree.c (build_cplus_array_type): Layout type before variants are
set, but
> -Original Message-
> From: Georg-Johann Lay [mailto:a...@gjlay.de]
> Sent: Thursday, April 09, 2015 4:54 PM
> To: Sivanupandi, Pitchumani; Denis Chertykov
> Cc: GCC Patches; Joerg Wunsch; Selvaraj, Senthil_Kumar
> Subject: Re: [patch,avr]: Part2: Fix various problems with specs and specs
On Wed, Apr 8, 2015 at 6:54 PM, Andi Kleen wrote:
>> On the STAMP suite of benchmarks for transactional memory (described here
>> [1]).
>> I have ran an unmodified GCC 5.0.0 against the patched GCC with these
>> modifications and obtain the following speedups in STAMP with 4
>> threads (on a Hasw
On 09 Apr 16:41, Jakub Jelinek wrote:
> Please use
> PR target/65671
> * config/i386/sse.md (vec_extract_hi_): ...
> (both PR line and name of pattern missing).
Sure, thanks!
--
K
On 04/08/2015 11:07 AM, Jakub Jelinek wrote:
But that is how handle_aligned_attribute works, since forever (checked it
back to 3.2). In <= 3.4.x, it used to create it using build_type_copy,
since 4.0.0 using build_variant_type_copy, but both those routines behave
the same - build a type variant
On Wed, Apr 08, 2015 at 11:00:59PM +0200, Jakub Jelinek wrote:
> On x86_64/i686 this only detects constraint G as not allowing reg nor mem
> (it is match_code const_double), and V (plus < and >, but those are
> hardcoded in stmt.c already) that it allows mem but not reg.
> On aarch64, in the first
gcc/ChangeLog:
2015-04-08 Bernhard Reutner-Fischer
PR target/55143
* c/c-tree.h (c_default_pointer_mode): Move declaration ...
* c-family/c-common.h (c_default_pointer_mode): ... here.
* c/c-decl.c (c_default_pointer_mode): Move definition ...
* c-family
On Wed, 21 May 2014, Jonathan Wakely wrote:
> Bootstrapped on x86_64-unknown-dragonfly3.6 and
> x86_64-unknown-linux-gnu, committed to trunk as
> http://gcc.gnu.org/r210694
>
> John, thanks for contributing the target support and for persevering
> with the review process :-)
And here is the corre
On Thu, Apr 09, 2015 at 07:41:17AM -0500, Segher Boessenkool wrote:
> It would be nice if there would be some cc0 target in the compile farm,
> since cc0 isn't going away any time soon :-(
>
> Okay if testing has finished successfully?
>
>
> Segher
>
>
> 2015-04-09 Segher Boessenkool
>
>
We've been debugging a problem where nul (and other control)
characters have been randomly appearing in powerpc parallel
build logs. In the process, I noticed that some of the nuls
are readily reproducible. One such case is due to
the pr32627.f03 test which verifies that Fortran programs
can initi
On 09 Apr 12:32, Gerald Pfeifer wrote:
> On Thu, 9 Apr 2015, Ilya Enkovich wrote:
> > This adds Pointer Bounds Checker and MPX support to GCC 5 changes.
> > Is it OK?
>
> Nice, thank you!
>
> Can you just replace "runtime checks" by "run-time checks" and
> "IA-32/x86-64 GNU/Linux target" by "x86
essentially s/[[:space:]]*[[:space:]];/;/g
ChangeLog (attn: to src, IIRC no write-access, ask someone to commit)
Ok for trunk now?
2015-04-01 Bernhard Reutner-Fischer
* Makefile.tpl: Remove surplus whitespace throughout.
* Makefile.in: Regenerate.
Signed-off-by: Bernhard Reu
> -Original Message-
> From: Georg-Johann Lay [mailto:a...@gjlay.de]
> Sent: Wednesday, April 08, 2015 4:56 PM
> To: Denis Chertykov
> Cc: Sivanupandi, Pitchumani; GCC Patches; Joerg Wunsch; Selvaraj,
> Senthil_Kumar
> Subject: Re: [patch,avr]: Part2: Fix various problems with specs and s
Dear All,
I intend to commit this patch tonight, unless there are objections. It
is safe, since it skips an ICE if the conditions in the ChangeLog are
met.
Bootstraps and regtests on x86_64/FC21.
Paul
2013-04-09 Paul Thomas
PR fortran/56852
* primary.c (gfc_variable_attr): Avoid ICE
On Thu, 9 Apr 2015, Ilya Enkovich wrote:
> This adds Pointer Bounds Checker and MPX support to GCC 5 changes.
> Is it OK?
Nice, thank you!
Can you just replace "runtime checks" by "run-time checks" and
"IA-32/x86-64 GNU/Linux target" by "x86/x86-64 GNU/Linux targets"
(x86, as we had agreed upon
On 04/09/2015 07:21 AM, Steven Bosscher wrote:
On Thu, Apr 9, 2015 at 2:41 PM, Segher Boessenkool wrote:
It would be nice if there would be some cc0 target in the compile farm,
since cc0 isn't going away any time soon :-(
In this case it would be enough to replace the "#ifndef/#ifdef
HAVE_cc0"
Hi,
This adds Pointer Bounds Checker and MPX support to GCC 5 changes. Is it OK?
Thanks,
Ilya
--
--- changes.html2015-04-09 12:18:47.67230 +0300
+++ changes.html2015-04-09 12:58:23.677983000 +0300
@@ -158,20 +158,29 @@
-fsanitize=alignment: enable alignment checking, d
Attached is an updated patch that fixes the substr_6.f90
test that also prints a nul character to stdout. I don't
think there are any others.
Besides interfering with the debugging of the log corruption
I mentioned, printing nuls or control characters in tests is
also problematic for tools design
On Thu, 9 Apr 2015, Segher Boessenkool wrote:
> I tested a cross to cris-linux and built a Linux kernel with the trivial
> patch (attached); doing that for all other cross configs is in progress.
Thanks. Using contrib/config-list.mk comes to mind, but might
be a bit excessive in this particular c
On Thu, Apr 09, 2015 at 03:21:44PM +0200, Steven Bosscher wrote:
> On Thu, Apr 9, 2015 at 2:41 PM, Segher Boessenkool wrote:
> > It would be nice if there would be some cc0 target in the compile farm,
> > since cc0 isn't going away any time soon :-(
>
> In this case it would be enough to replace t
On 9 April 2015 at 21:41, Jakub Jelinek wrote:
> On Thu, Apr 09, 2015 at 09:27:34PM +0200, Bernhard Reutner-Fischer wrote:
>> gcc/ChangeLog:
>>
>> 2015-04-08 Bernhard Reutner-Fischer
>>
>> PR target/55143
>> * c/c-tree.h (c_default_pointer_mode): Move declaration ...
>> * c-fa
Hi!
As can be seen on the following testcase, instrument_mem_ref (for
both -fsanitize=alignment and -fsanitize=null) has been using wrong type
to find out what is the access type - instead of the type of MEM_REF
which is the access type it was using the TREE_TYPE of MEM_REF's argument
type, which
Hi
On 7 April 2015 at 22:02, Yvan Roux wrote:
> On 7 April 2015 at 21:33, Jakub Jelinek wrote:
>> On Tue, Apr 07, 2015 at 09:28:51PM +0200, Yvan Roux wrote:
>>> validation is ongoing, but here is my attempt to add this testcase,
>>> does it look correct (it's the first time I use that kind of in
On Wed, Apr 08, 2015 at 12:02:39PM +0200, Jakub Jelinek wrote:
> The included (first) patch has been successfully bootstrapped/regtested on
> x86_64-linux and i686-linux, the attached patch not, but I can
> bootstrap/regtest it if you prefer it.
The attached version unfortunately regresses pr60226
On Thu, Apr 9, 2015 at 4:37 PM, Kirill Yukhin wrote:
> Patch in the bottom fixes PR target/65671.
>
> It simply generates vextract32x4 (float form) for double extract.
>
> Bootstrap & regtesting in progress.
>
> I'll check it in if pass and back port to 4.9.x.
> Feel free comment.
>
> gcc/
>
On Wed, Apr 8, 2015 at 11:28 AM, Jonathan Wakely wrote:
> On 08/04/15 19:40 +0200, Jakub Jelinek wrote:
>>
>> Hi!
>>
>> Attached patch updates baseline_symbols.txt for a couple of architectures.
>> Don't have 32-bit powerpc-linux around though this time.
>>
>> Ok for trunk?
>
>
> OK, thanks very m
On 09/04/15 08:44 -0700, H.J. Lu wrote:
I checked in this patch to update x32 baseline_symbols.txt:.
Great, thanks.
Hi Paul, hi all,
Paul, thanks for the review. Answers to your questions are inline below:
On Sun, 5 Apr 2015 11:13:05 +0200
Paul Richard Thomas wrote:
> + /* The dummy is returned for pointer, allocatable or assumed rank arrays.
> + The check for pointerness needs to be repeated here (it i
On Wed, Apr 08, 2015 at 10:29:03PM -0400, Hans-Peter Nilsson wrote:
> On Wed, 8 Apr 2015, Segher Boessenkool wrote:
> > 2015-04-08 Segher Boessenkool
> >
> > * combine.c (is_parallel_of_n_reg_sets): Change first argument
> > from an rtx_insn * to an rtx.
> > (try_combine): Adjust bot
On April 9, 2015 8:11:22 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>As can be seen on the following testcase, instrument_mem_ref (for
>both -fsanitize=alignment and -fsanitize=null) has been using wrong
>type
>to find out what is the access type - instead of the type of MEM_REF
>which is the acces
I've committed the following trivial patch to trunk (as r221959).
gcc/jit/ChangeLog:
PR jit/65691
* docs/cp/topics/expressions.rst (Simple expressions): Fix copy
and paste error in description of gccjit::context::one.
* docs/topics/expressions.rst (Simple expression
Am 04/09/2015 um 12:59 PM schrieb Sivanupandi, Pitchumani:
And what about the spaces problem as mentioned in
http://savannah.nongnu.org/bugs/?44574
http://lists.gnu.org/archive/html/avr-libc-dev/2015-03/msg00010.html
Art there plans to fix that?
Yes. Will submit patch to avr-libc by next week
On Thu, Apr 09, 2015 at 09:27:34PM +0200, Bernhard Reutner-Fischer wrote:
> gcc/ChangeLog:
>
> 2015-04-08 Bernhard Reutner-Fischer
>
> PR target/55143
> * c/c-tree.h (c_default_pointer_mode): Move declaration ...
> * c-family/c-common.h (c_default_pointer_mode): ... here.
>
On Thu, Apr 09, 2015 at 01:10:41PM +0200, Yvan Roux wrote:
> 2105-04-09 Yvan Roux
>
> PR target/65648
> * gcc.c-torture/execute/pr65648.c: New test.
This part is definitely ok for trunk.
> * gcc.target/arm/pr65648.c: New test.
This part should better be reviewed by so
Applied this patch:
http://gcc.gnu.org/r221947
Johann
* config/avr/driver-avr.c (avr_devicespecs_file): Don't specify a
device specs file if "device-specs%s" didn't resolve to a path.
Index: config/avr/driver-avr.c
==
Hi,
It turns out that existing versions of clang (used as bootstrap on later Darwin
editions) support -mdynamic-no-pic, but not the inverse. The patch below
revises mh-darwin so that it only adds -mdynamic-no-pic when the inverse is
supported (for stage1 and boot cflags). For later stages, bu
50 matches
Mail list logo
