From: Trevor Saunders
Hi,
comments fixed. bootstrapped on x86_64-linux, new test passes and regtest
pending, ok?
Trev
c-family/
* c.opt (Wsuggest-override): New option.
cp/
* class.c (check_for_override): Warn when a virtual function is an
override not marked overr
On Tue, Dec 23, 2014 at 6:59 PM, Jeff Law wrote:
> On 12/23/14 19:47, H.J. Lu wrote:
>>
>> On Tue, Dec 23, 2014 at 6:16 PM, John David Anglin
>> wrote:
>>>
>>> On 23-Dec-14, at 7:28 PM, H.J. Lu wrote:
>>>
On Tue, Dec 23, 2014 at 3:55 PM, John David Anglin
wrote:
>
>
>
On 12/23/14 19:47, H.J. Lu wrote:
On Tue, Dec 23, 2014 at 6:16 PM, John David Anglin wrote:
On 23-Dec-14, at 7:28 PM, H.J. Lu wrote:
On Tue, Dec 23, 2014 at 3:55 PM, John David Anglin
wrote:
On 23-Dec-14, at 5:37 PM, H.J. Lu wrote:
In this case, arguments are passed in registers. Isn't
On Tue, Dec 23, 2014 at 6:16 PM, John David Anglin wrote:
> On 23-Dec-14, at 7:28 PM, H.J. Lu wrote:
>
>> On Tue, Dec 23, 2014 at 3:55 PM, John David Anglin
>> wrote:
>>>
>>> On 23-Dec-14, at 5:37 PM, H.J. Lu wrote:
>>>
In this case, arguments are passed in registers. Isn't the
optimi
On 23-Dec-14, at 7:28 PM, H.J. Lu wrote:
On Tue, Dec 23, 2014 at 3:55 PM, John David Anglin > wrote:
On 23-Dec-14, at 5:37 PM, H.J. Lu wrote:
In this case, arguments are passed in registers. Isn't the
optimization
disabled for ia32, which passes arguments on stack, even before your
change?
And now with a patch...
I tried this patch a year ago and, as pointed out by NightStrike, got
lost in the shuffle.
The idea is that default arguments in literal operators would lead to
ambiguities and might not act like the uthor intends.
The earlier patch errors out. This time I just warn
I tried this patch a year ago and, as pointed out by NightStrike, got
lost in the shuffle.
The idea is that default arguments in literal operators would lead to
ambiguities and might not act like the uthor intends.
The earlier patch errors out. This time I just warn. I'm not sure what
we w
ChangeLog
2014-12-23 James Bowman
* config.sub: Update from upstream config repo.
--
James Bowman
FTDI Open Source Liaison
Index: config.sub
===
--- config.sub (revision 219020)
+++ config.sub (working copy)
@@ -2,7 +2,
On Tue, Dec 23, 2014 at 3:55 PM, John David Anglin wrote:
> On 23-Dec-14, at 5:37 PM, H.J. Lu wrote:
>
>> In this case, arguments are passed in registers. Isn't the optimization
>> disabled for ia32, which passes arguments on stack, even before your
>> change?
>
>
> It's not disabled in dse.c.
On 23-Dec-14, at 5:37 PM, H.J. Lu wrote:
In this case, arguments are passed in registers. Isn't the
optimization
disabled for ia32, which passes arguments on stack, even before your
change?
It's not disabled in dse.c. Possibly, this occurs for some cases for
ia32 in ix86_function_ok_for
Rather than the patch linked to in the PR comments this does it
properly, by compiling locale-inst.cc as C++11 (so the new time_get
members are instantiated).
Tested powerpc64-linux, committed to trunk.
commit 41ecb70e823f723f8c24c2ad227a5d0d567f5af1
Author: Jonathan Wakely
Date: Tue Dec 23 1
On Tue, Dec 23, 2014 at 2:24 PM, John David Anglin wrote:
> On 2014-12-23 12:32 PM, H.J. Lu wrote:
>>
>> On Tue, Dec 16, 2014 at 5:17 PM, John David Anglin
>> wrote:
>>>
>>> On 8-Dec-14, at 5:36 PM, Jeff Law wrote:
>>>
On 12/08/14 15:15, John David Anglin wrote:
>
> On 12/8/2014 3:01
On 2014-12-23 12:32 PM, H.J. Lu wrote:
On Tue, Dec 16, 2014 at 5:17 PM, John David Anglin wrote:
On 8-Dec-14, at 5:36 PM, Jeff Law wrote:
On 12/08/14 15:15, John David Anglin wrote:
On 12/8/2014 3:01 PM, Jeff Law wrote:
The above is wrong for sibcalls. Sibcall arguments are relative
to the
OK, thanks.
Jason
Hi,
On 12/23/2014 07:13 PM, Jason Merrill wrote:
On 12/23/2014 11:30 AM, Paolo Carlini wrote:
if (maybe_range_for_decl)
-*maybe_range_for_decl = error_mark_node;
+{
+ *maybe_range_for_decl = error_mark_node;
+ if (*equal_loc == UNKNOWN_LOCATION)
+tmp_equal_loc
The gc Go compiler supports a race detector, and some of the support
for that has been copied into libgo. It is useless there because
gccgo does not support a race detector, and the calls are normally
optimized away. However, this does not occur when the library is
built without optimization. Th
Hello Jonathan,
starting with around r218964, "New std::string implementation."
the following program does no longer link correctly:
cat test1.cc
#include
int
main()
{
std::string x;
x.erase(x.begin(), x.end());
}
g++ test1.cc
/tmp/ccgup1FU.o: In function `main':
test1.cc:(.text+0x41): u
Mike Stump writes:
Thanks for doing that. I missed this pragma several times.
> I didn’t engineer ivdeps and unroll together. Does it sound
> reasonable to allow both to be used at the same time on the same loop?
> If so, I can add the two other cases, presently I just handle one of
> them then
On 12/22/14 04:14, Eric Botcazou wrote:
Revised version after Joseph's comments and latest libgcc changes.
gcc/ChangeLog
2014-12-22 Eric Botcazou
* config.gcc: Add Visium support.
* configure.ac: Likewise.
* configure: Regenerate.
* doc/extend.texi (interrup
On 12/22/14 18:28, Zhouyi Zhou wrote:
Thanks Jeff for reviewing,
I forget to mention that I do not have write access
to gcc.
Can you install for me ?
Done. Thanks,
Jeff
..., because that's not needed.
---
tools/Makefile.in | 2 +-
tools/configure| 4 +---
tools/configure.ac | 6 ++
3 files changed, 4 insertions(+), 8 deletions(-)
diff --git tools/Makefile.in tools/Makefile.in
index f007b83..2886fe6 100644
--- tools/Makefile.in
+++ tools/Makefile.in
@@ -
Also remove the LIBPATH define, which is not used anywhere.
---
tools/Makefile.in | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git tools/Makefile.in tools/Makefile.in
index 8dcedbc..f007b83 100644
--- tools/Makefile.in
+++ tools/Makefile.in
@@ -1,10 +
GCC needs this, if nvptx-none-ar and nvptx-none-ranlib aren't found in $PATH.
---
tools/Makefile.in | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git tools/Makefile.in tools/Makefile.in
index 6829e29..8dcedbc 100644
--- tools/Makefile.in
+++ tools/Makefile.in
@@ -45,11
Hi!
On Mon, 10 Nov 2014 17:19:57 +0100, Bernd Schmidt
wrote:
> The scripts (11/11) I've put up on github, along with a hacked up
> newlib. These are at
>
> https://github.com/bernds/nvptx-tools
> https://github.com/bernds/nvptx-newlib
>
> They are likely to migrate to MentorEmbedded from bern
The Go frontend failed to copy an array in a range statement. The
effect was that if the code in the loop changed future elements of the
original array, it would incorrectly change the results of the
iteration. This patch from Chris Manghane fixes the problem. This
issue 34 in the gofrontend iss
On 12/23/2014 11:30 AM, Paolo Carlini wrote:
if (maybe_range_for_decl)
- *maybe_range_for_decl = error_mark_node;
+ {
+ *maybe_range_for_decl = error_mark_node;
+ if (*equal_loc == UNKNOWN_LOCATION)
+ tmp_equal_loc = token->location;
Even though the
Hi!
In r219044, I have committed a merge from trunk r218997 (2014-12-21) into
gomp-4_0-branch.
This includes updating our Fortran front end changes for using plain
flag_openacc instead of gfc_option.gfc_flag_openacc, but I have not yet
updated most of our changes for the other recent Fortran fron
On Tue, Dec 16, 2014 at 5:17 PM, John David Anglin wrote:
> On 8-Dec-14, at 5:36 PM, Jeff Law wrote:
>
>> On 12/08/14 15:15, John David Anglin wrote:
>>>
>>> On 12/8/2014 3:01 PM, Jeff Law wrote:
>
> The above is wrong for sibcalls. Sibcall arguments are relative
> to the incoming arg
On 03/12/14 15:03, Andrew Stubbs wrote:
The tools have always allowed us to drop down the arch to
march=armv5te along with using -mfpu=neon. We are now changing command
line behaviour, so an inform in terms of diagnostics to the user would
be useful as it states that we don't really have mfpu=neo
Hi again,
thus, in order to deal with the various subissues we have got, I
prepared the below, which passes testing. As you can see, the diagnostic
triggers only once, for the left-most '=' and/or the left-most ','. I
suppose that's Ok, I'm not 100% sure about the wording of the error
message
.. and, to make things more interesting ;) for:
for (int a, b, c: arr)
we currently give:
63985.C:7:19: error: expected initializer before ‘:’ token
63985.C:7:21: warning: range-based ‘for’ loops only available with
-std=c++11 or -std=gnu++11
because, inside cp_parse_init_declarator we ar
31 matches
Mail list logo
