On Sat, May 10, 2014 at 12:13 PM, Andrew Burgess wrote:
> On 09/05/2014 9:53 PM, Ian Lance Taylor wrote:
>> On Fri, May 9, 2014 at 7:35 AM, Andrew Burgess wrote:
>>
>>>if ((AUTO_DEMANGLING || GNU_DEMANGLING))
>>> {
>>> success = gnu_special (work, &mangled, &decl);
>>> +
Hi,
This patch fixes a bogus warning generated by -Wmaybe-uninitialized.
The problem is that we sometimes fail to acknowledge a defining edge
belonging to a control-dependence chain because we assume that each
defining edge shares the same control-dependence root. But this may not
be true if a de
Ping.
Thanks,
bin
On Tue, May 6, 2014 at 12:59 PM, bin.cheng wrote:
>
>
>> -Original Message-
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>> ow...@gcc.gnu.org] On Behalf Of bin.cheng
>> Sent: Monday, May 05, 2014 3:21 PM
>> To: Richard Earnshaw
>> Cc: gcc-patches@gcc.gnu.
I don't have permissions to commit this patch, but I do have a release
on file with the FSF.
Problem description:
The existing docs make reference to a macro which "is described below."
However, this is the final sentence in the section; there is no
"below." Turns out the macro was deleted a
Ping ?
Thanks,
Kugan
On 02/05/14 19:04, Kugan wrote:
> On 02/05/14 10:15, Joseph S. Myers wrote:
>> It doesn't seem a good idea to me for a host-side GCC file to use the FE_*
>> names for the target's FE_* values; you'd run into problems if that file
>> ever ends up including the host's , direc
Ping ?
Thanks,
Kugan
On 02/05/14 22:27, Kugan wrote:
>
>
> On 02/05/14 20:06, Marcus Shawcroft wrote:
>> On 29 April 2014 03:37, Kugan wrote:
>>>
>>> On 28/04/14 21:01, Ramana Radhakrishnan wrote:
On 04/26/14 11:57, Kugan wrote:
> Attached patch implements TARGET_ATOMIC_ASSIGN_EXPAND_F
On Mon, May 12, 2014 at 08:23:16AM +0930, Alan Modra wrote:
> On Sat, May 10, 2014 at 10:24:34PM -0400, David Edelsohn wrote:
> > On Thu, May 8, 2014 at 10:40 PM, Alan Modra wrote:
> > > rs6000_emit_set_const ... always returns a non-zero result ...
> >
> > Can you help clarify the removal of the
On Sat, May 10, 2014 at 10:24:34PM -0400, David Edelsohn wrote:
> On Thu, May 8, 2014 at 10:40 PM, Alan Modra wrote:
> > rs6000_emit_set_const ... always returns a non-zero result ...
>
> Can you help clarify the removal of the code that tests if the
> splitter failed?
See above.
--
Alan Modra
That test now looks a bit silly with the dozen+1 exceptions. But, I
guess with just this one(?) test there's little sense in adding an
effective target to describe that division by 0 doesn't signal. Other
than keeping it in just one place, of course. But, committed.
gcc/testsuite:
* gcc
On Sun, May 11, 2014 at 09:18:47PM +0200, Rainer Orth wrote:
> No, that's wrong: avoid hardcoding target lists if at all possible.
> Besides, it's wrong since it doesn't cover the Solaris (and other
> non-gld linker) case. Use the init_priority effective-target keyword
> instead. Also, please che
Marek Polacek writes:
>> The errors are
>>
>> /opt/gcc/work/gcc/testsuite/c-c++-common/pr50459.c:8:1: error: constructor
>> priorities are not supported
>> /opt/gcc/work/gcc/testsuite/c-c++-common/pr50459.c:9:1: error: destructor
>> priorities are not supported
>
> Ah. The following untested
On 02 May 2014, at 17:57, Jonathan Wakely wrote:
> On 1 May 2014 17:18, Oleg Endo wrote:
>> Jonathan,
>>
>> now that we're in stage 1 again, I'd like to revive the issue below. Do
>> you have any particular plans? How should we proceed?
>
> Hi Oleg, sorry for letting the thread die in Januar
> ===
> --- gcc/builtins.c(revision 210019)
> +++ gcc/builtins.c(working copy)
> @@ -87,6 +87,9 @@ static rtx result_vector (int, rtx);
> #endif
> static void expand_builtin_update_setjmp_buf (rtx);
> static void expand_buil
While it would be nice to support "!$OMP do" for "do concurrent" loops,
the OpenMP spec does not support it, yet. (Syntactically, it is a not a
that simple feature as do concurrent can optionally have a MASK=, which
has to be evaluated before the loop.)
Thus, this patch avoids an ICE by simply
This patch changes the type of second argument to
_gfortran_caf_num_images from Boolean to integer. The reason is that we
have to represent three different states:
a) num_images() - all existing images (in the current/"distance"-th
parent team)
b/c) num_images(...,failed) - those states which h
On Sat, May 10, 2014 at 04:10:47PM +0200, Dominique Dhumieres wrote:
> > ...
> > Tested again x86_64-linux, ok now?
> >
> > 2014-05-02 Marek Polacek
> >
> > PR c/50459
>
> This caused on x86_64-apple-darwin13
>
> FAIL: c-c++-common/pr50459.c -std=gnu++98 (test for excess errors)
> FAIL: c-
On May 11, 2014 3:54:30 PM CEST, Steven Bosscher wrote:
>Hello,
>
>This patch plugs a GGC leak in gcse.c, which will hold on to test insn
>to save memory. But this results in holding on to entire RTL function
>bodies, the function's CFG, and a lot more.
>
>Fix is simple: Clear the part of test_ins
Hello,
This patch plugs a GGC leak in gcse.c, which will hold on to test insn
to save memory. But this results in holding on to entire RTL function
bodies, the function's CFG, and a lot more.
Fix is simple: Clear the part of test_insn that causes this.
Bootstrapped&tested on powerpc64-unknown-li
PING
On Thu, May 1, 2014 at 12:57 AM, Janne Blomqvist
wrote:
> Hello,
>
> the attached patch switches libgfortran C sources to be compiled in
> gnu11 mode instead of gnu99. As the 4.9 release notes
> http://gcc.gnu.org/gcc-4.9/changes.html say,
>
> "ISO C11 support is now at a similar level of co
PING
On Sat, May 3, 2014 at 11:47 PM, Janne Blomqvist
wrote:
> Hello,
>
> the attached patch avoids a stack overflow crash due to not trying to
> create a null-terminated duplicate of the argument char array on the
> stack. Also, for the common case it avoids an extra allocation and an
> extra me
On Thu, May 8, 2014 at 5:08 PM, Bin.Cheng wrote:
> On Tue, May 6, 2014 at 6:44 PM, Richard Biener
> wrote:
>> On Tue, May 6, 2014 at 10:39 AM, Bin.Cheng wrote:
>>> On Fri, Dec 6, 2013 at 6:19 PM, Richard Biener
>>> wrote:
>
>>> Hi,
>>> I split the patch into two and updated the test case.
>>> T
On Sat, May 10, 2014 at 9:11 PM, Richard Sandiford
wrote:
> The wide-int version of int_const_binop_1 has:
>
> static tree
> int_const_binop_1 (enum tree_code code, const_tree arg1, const_tree parg2,
>int overflowable)
> {
> [...]
> tree type = TREE_TYPE (arg1);
> [...]
>
Hi,
currently it is not possible to build GCC's libjava support on Cygwin-64.
The attached patch fixes the current build-problems and the most
fundamental bugs on that platform.
Note you must still add --enable-threads=posix to successfully build the
java language support.
Boot-Strapped on Cygwi
For those with a broken crystal ball (and being too lazy to look in the
repository), here's the attachment.
Tobias Burnus:
A rather obvious copy and paste error ...
Committed as Rev. 210309.
Index: libgfortran/ChangeLog.fortran-caf
=
On Sat, 10 May 2014, Andrew Pinski wrote:
On Sat, May 10, 2014 at 3:53 PM, Marc Glisse wrote:
Hello,
in my recent phiopt patch enhancing value_replacement to optimize
x!=0?x+y:y, I forgot to check that there is no other PHI (not sure how I
managed to miss that since I copy-pasted the line jus
A rather obvious copy and paste error ...
Committed as Rev. 210309.
Tobias
The test case checked array[idx]=array and array[idx]=scalar assignment,
but not scalar[idx]=scalar assignments.
I have now added the check; committed as Rev. 210308.
Tobias
Index: gcc/testsuite/ChangeLog.fortran-caf
===
--- gcc/te
27 matches
Mail list logo
