You are right, it's my fault.
thanks a lot
Carrot
On Fri, Mar 29, 2013 at 6:33 PM, Alan Modra amo...@gmail.com wrote:
On Fri, Mar 29, 2013 at 04:58:50PM -0700, Carrot Wei wrote:
/trunkbin/bin/gcc -c -o rtl.o -DSPEC_CPU -DNDEBUG -I. -O2
-DSPEC_CPU_LP64 -m32rtl.c
You've given
Hey guys,
I'm still planning to rewrite the c++ parser in GCC, right now I am still
researching, I remember a page that talked about the problems of parsing in
nested templates, and I cannot find the link!
Searching for it has yielded people asking questions about errors where
occurs.
On Mon, Apr 1, 2013 at 8:55 AM, Alec Teal a.t...@warwick.ac.uk wrote:
I'm still planning to rewrite the c++ parser in GCC, right now I am still
researching, I remember a page that talked about the problems of parsing in
nested templates, and I cannot find the link!
Searching for it has
Hi,
replacing my AMD Phenom2 with a AMD Piledriver (Bulldozer Version2)
was reason enough for me to recompile gcc (and the whole linux-system)
with hard optimisation set to bdver2 (as I've done since my first
linux on an 68030).
But this time an increasing number of errors makes me a little bit
On 01/04/13 17:41, Ian Lance Taylor wrote:
On Mon, Apr 1, 2013 at 8:55 AM, Alec Teal a.t...@warwick.ac.uk wrote:
I'm still planning to rewrite the c++ parser in GCC, right now I am still
researching, I remember a page that talked about the problems of parsing in
nested templates, and I
On 1 April 2013 20:43, Alec Teal wrote:
I don't have a link, but it seems to me that the issue is obvious.
The C++ lexer recognizes as a single token. So when you write
std::vectorstd::vectorint
the final is parsed as a single token, rather than the two separate
tokens that the parser
On 01/04/13 21:08, Jonathan Wakely wrote:
On 1 April 2013 20:43, Alec Teal wrote:
[snip]
Yes that is (was) the problem, I remember reading a document online, I cannot
recall where that looked at three ways of solving it and evaluated them, I know
of the problem but I want that guy's
On 03/30/2013 02:23 AM, Senthil Kumar Selvaraj wrote:
I couldn't find a way to ask gcc to just generate DWARF (default
version) either. How should this be fixed?
Maybe we could use -gdwarf for that now, since we stopped using it for
DWARF 1 in GCC 3.4.
Jason
On Apr 1, 2013, at 6:43 PM, Jason Merrill ja...@redhat.com wrote:
On 03/30/2013 02:23 AM, Senthil Kumar Selvaraj wrote:
I couldn't find a way to ask gcc to just generate DWARF (default
version) either. How should this be fixed?
Maybe we could use -gdwarf for that now, since we stopped using
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55583
--- Comment #5 from Marc Glisse glisse at gcc dot gnu.org 2013-04-01 13:45:33
UTC ---
Created attachment 29764
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29764
Patch from comment #4
I apparently forgot to attach a patch when I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #22 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-01
14:17:45 UTC ---
(In reply to comment #13)
and didn't need to be translated. So, printf (%.*d); (the common case)
wouldn't have to be recorded, while printf (R(%) .
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Attachment #29753|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #24 from Paolo Carlini paolo.carlini at oracle dot com 2013-04-01
14:32:27 UTC ---
(Nit: careful with the GCC coding style, eg, open curly bracket on a new line)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56799
Bug #: 56799
Summary: Runfail after r197060+r197082.
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56799
--- Comment #1 from Yuri Rumyantsev ysrumyan at gmail dot com 2013-04-01
14:51:28 UTC ---
It is sufficient to compile test with '-O2' option.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56800
Bug #: 56800
Summary: [fortran-dev Regression] move_alloc_13.f90 failure
Classification: Unclassified
Product: gcc
Version: fortran-dev
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52436
--- Comment #2 from Marc Glisse glisse at gcc dot gnu.org 2013-04-01 15:14:59
UTC ---
Created attachment 29767
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29767
patch
This patch may be a bit too strong. In particular, it breaks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50269
Rich Townsend townsend at astro dot wisc.edu changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56500
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56798
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56798
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56801
Bug #: 56801
Summary: Internal Compiler Error when compiling relaxed
transaction
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56801
--- Comment #1 from Mike Spear spear at cse dot lehigh.edu 2013-04-01
15:55:04 UTC ---
Created attachment 29768
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29768
C file that generates the ICE
I forgot to include the output of gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119
Thomas Koenig tkoenig at gcc dot gnu.org changed:
What|Removed |Added
Depends on||37131
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45882
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
CC||steven
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56802
Bug #: 56802
Summary: --with-build-sysroot does not affect library search
directories
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56802
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-04-01
17:01:15 UTC ---
I think the trick is to compile a cross compiler and then another cross
compiler where the host==target!=build.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56800
--- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-04-01
17:05:35 UTC ---
The stride needs to be set from the source; it currently
is taken from y (which is an empty type, hence the 0
for sm).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56802
--- Comment #2 from Booty Bootstrapper e515181 at rmqkr dot net 2013-04-01
17:06:57 UTC ---
How does this solve the problem? What is wrong with linking to the libs in
/tmp/sysrootd - after all, the headers in /tmp/sysrootd are used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56802
--- Comment #3 from Booty Bootstrapper e515181 at rmqkr dot net 2013-04-01
17:08:44 UTC ---
I am not cross compiling. The machine of the host is exactly the one of the
target. Host and target use different versions of glibc, though.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56731
--- Comment #8 from janus at gcc dot gnu.org 2013-04-01 17:10:13 UTC ---
(In reply to comment #1)
Trunk gives:
select type(an = carr%c)
1
Error: Component to the right of a part reference with nonzero rank
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56802
--- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2013-04-01
17:13:47 UTC ---
(In reply to comment #3)
I am not cross compiling. The machine of the host is exactly the one of the
target. Host and target use different
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56802
--- Comment #5 from Booty Bootstrapper e515181 at rmqkr dot net 2013-04-01
17:24:17 UTC ---
(In reply to comment #4)
(In reply to comment #3)
I am not cross compiling. The machine of the host is exactly the one of the
target. Host
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56802
--- Comment #6 from Booty Bootstrapper e515181 at rmqkr dot net 2013-04-01
17:43:05 UTC ---
(In reply to comment #5)
Is there any way to prevent this dance? I do not care about bootstrapping at
this point, I just need a working compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56800
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-01
18:01:03 UTC ---
The problem is in gfc_array_init_size. There, one should first obtain the
element size. And instead of gfc_conv_descriptor_stride_set one should use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45882
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-01
18:11:07 UTC ---
ENTRY_VALUE's operand is 0, because in most cases you don't want to let the
various RTL passes to see through the ENTRY_VALUE rtl, they should treat the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56803
Bug #: 56803
Summary: EOF with namelist read give INTERNAL error instead of
END OF FILE error
Classification: Unclassified
Product: gcc
Version: 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56794
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56793
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56803
--- Comment #1 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2013-04-01
20:10:02 UTC ---
This is fixed on 4.9 by patch to PR56786, but it patch does need to be
backported.
$ gfc tc56803.f90
$ ./a.out
At line 8 of file tc56803.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56803
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56786
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-01
20:26:22 UTC ---
*** Bug 56803 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56786
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56786
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56772
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56660
--- Comment #2 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2013-04-01
20:33:52 UTC ---
Author: jvdelisle
Date: Mon Apr 1 20:30:41 2013
New Revision: 197321
URL: http://gcc.gnu.org/viewcvs?rev=197321root=gccview=rev
Log:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56660
--- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2013-04-01
21:00:36 UTC ---
Author: jvdelisle
Date: Mon Apr 1 20:59:34 2013
New Revision: 197322
URL: http://gcc.gnu.org/viewcvs?rev=197322root=gccview=rev
Log:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45917
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55241
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55931
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55240
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55017
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54946
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54532
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56794
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56793
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56772
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56800
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-01
21:34:55 UTC ---
Created attachment 29769
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29769
Early draft patch
The patch mostly implements a fix for this bug -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55951
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56804
Bug #: 56804
Summary: lto1: internal compiler error: bytecode stream: found
non-null terminated string
Classification: Unclassified
Product: gcc
Version: 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56804
--- Comment #1 from Vincent vchou79 at gmail dot com 2013-04-01 22:21:14 UTC
---
Created attachment 29770
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29770
preprocessed sources
--enable-languages=c,c++,fortran
--disable-multilib
Thread model: posix
gcc version 4.9.0 20130401 (experimental) (GCC)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56804
--- Comment #2 from Vincent vchou79 at gmail dot com 2013-04-01 23:17:55 UTC
---
introduced by http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=196864
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56805
Bug #: 56805
Summary: DW_AT_typedef missing when -fdebug-types-section is
used (and -fno-eliminate-unused-debug-types)
Classification: Unclassified
Product: gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56805
--- Comment #1 from Jan Smets jan.sm...@alcatel-lucent.com 2013-04-01
23:33:18 UTC ---
And the typedef names should have an entry , regardless of
-fdebug-types-section because -fno-eliminate-unused-debug-types is used.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
incrediball peter at axium dot co.nz changed:
What|Removed |Added
CC||peter at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48318
Scott L. Burson Scott at sympoiesis dot com changed:
What|Removed |Added
CC|
On Wed, 27 Mar 2013, Eric Botcazou wrote:
int is getting small to store one bit per vector element (V32QI...) so I
switched to hwint after checking that Zadeck's patches don't touch this.
unsigned HOST_WIDE_INT is indeed the correct type to use for mask manipulation
but please use UINTVAL
On 27.02.2013 13:03, Andrey Belevantsev wrote:
Hello,
For this volatile-related issue (no volatile bits on volatile fields of a
non-volatile struct) AFAIU there is an agreement of fixing the front-ends
if needed, but anyways the patch to the selective scheduler is required
that properly merges
On 22.02.2013 17:30, Andrey Belevantsev wrote:
Hello,
As found by Jakub and explained in the PR audit trail by Alexander, this
patch fixes the selective scheduler merge glitch of 2008 that added the
unnecessary JUMP_P check to the flush_pending_lists call. I have removed
the check and expanded
On 19.02.2013 17:13, Andrey Belevantsev wrote:
Hello,
As we discussed in the PR, the problem here is that the selective scheduler
does not expect that renaming a hard register to a pseudo would result in
extra dependencies. The dependencies come from implicit clobbers code of
sched-deps.c, so
Hi,
On 04/01/2013 02:00 AM, Gerald Pfeifer wrote:
Andi's patch broke bootstrap on all FreeBSD platforms, which took me
a bit to realize since he did not update the ChangeLog:
2013-03-23 Andi Kleen a...@my.domain.org
* local_atomic (__always_inline): Add.
This page now goes to the general AMD press release page, which we
don't want to link to (and which does not have the original information
anymore). So, gone it is.
Gerald
Index: readings.html
===
RCS file:
Fix test case sra-13.c that assumed int is always 4 bytes.
Regards,
Pitchumani
2013-04-01 Pitchumani Sivanupandi pitchuman...@atmel.com
testsuite
* gcc.dg/tree-ssa/sra-13.c: Fix for 16 bit int
--- gcc/testsuite/gcc.dg/tree-ssa/sra-13.c (revision 197081)
+++
Ping!
(I hope I didn't anti-advertise this patch too much ;)
2013/3/20 Janus Weil ja...@gcc.gnu.org:
Hi all,
here is a simple patch which fixes some problems with IMPLICT
CLASS(...) statements. Actually that's not a feature I would seriously
recommend anyone to use, but the Fortran
On 04/01/2013 07:03 AM, Janus Weil wrote:
Ping!
(I hope I didn't anti-advertise this patch too much ;)
OK for trunk.
Jerry
Hi Janus,
Ping!
(I hope I didn't anti-advertise this patch too much ;)
2013/3/20 Janus Weil ja...@gcc.gnu.org:
Hi all,
here is a simple patch which fixes some problems with IMPLICT
CLASS(...) statements. Actually that's not a feature I would seriously
recommend anyone to use, but the
2013-04-01 Catherine Moore c...@codesourcery.com
* config/mips/mips.md (*movhi_internal, *movqi_internal): New
operands. Record compression.
Index: mips.md
===
--- mips.md (revision 197114)
+++ mips.md
On Android pthread is integrated into libc.
Attached patch fixes configures for this case by trying to build test
without -pthread -lpthread.
2013-04-01 Pavel Chupin pavel.v.chu...@intel.com
Fix libatomic and libgomp configure for systems without libpthread
*
Hello!
A part of an error has been demoted to a note recently. Attached
patch fixes a testcase in the obj-c++ testsuite.
2013-04-01 Uros Bizjak ubiz...@gmail.com
* obj-c++.dg/try-catch-13.mm: Use dg-message for
initializing argument note.
Tested on x86_64-pc-linux-gnu.
OK for
Ping!
(I hope I didn't anti-advertise this patch too much ;)
2013/3/20 Janus Weil ja...@gcc.gnu.org:
Hi all,
here is a simple patch which fixes some problems with IMPLICT
CLASS(...) statements. Actually that's not a feature I would seriously
recommend anyone to use, but the Fortran
Fix an error I made in one of the non-mechanical changes of r197234.
PR middle-end/56798
* cfgbuild.c (inside_basic_block_p): Restore check broken at r197234.
Index: cfgbuild.c
===
--- cfgbuild.c (revision 197267)
On Sat, 30 Mar 2013, Marc Glisse wrote:
* tree-flow-inline.h (get_addr_base_and_unit_offset_1): Handle
BIT_FIELD_REF.
I wrote a safer version of this for PR52436:
case BIT_FIELD_REF:
- return NULL_TREE;
+ {
+ HOST_WIDE_INT this_off =
Hi,
three items:
- Remove DECL_UNBOUND_CLASS_TEMPLATE_P, unused outside cp-tree.h.
- Use get_containing_scope in 4 places (obvious I guess)
- Use existing predicates in 2 places (likewise)
Tested x86_64-linux. Ok?
Thanks,
Paolo.
PS: In my opinion we should also rename DECL_FUNCTION_MEMBER_P
On 04/01/2013 12:41 PM, Paolo Carlini wrote:
+#define DECL_FUNCTION_TEMPLATE_P(NODE) \
+ (TREE_CODE (NODE) == TEMPLATE_DECL\
+DECL_TEMPLATE_RESULT (NODE) != NULL_TREE \
Do we need the NULL_TREE check? That is, do we
Hi,
On 04/01/2013 06:50 PM, Jason Merrill wrote:
On 04/01/2013 12:41 PM, Paolo Carlini wrote:
+#define DECL_FUNCTION_TEMPLATE_P(NODE) \
+ (TREE_CODE (NODE) == TEMPLATE_DECL \
+DECL_TEMPLATE_RESULT (NODE) != NULL_TREE\
Do we need the NULL_TREE check?
Hi again
On 04/01/2013 06:55 PM, Paolo Carlini wrote:
Hi,
On 04/01/2013 06:50 PM, Jason Merrill wrote:
On 04/01/2013 12:41 PM, Paolo Carlini wrote:
+#define DECL_FUNCTION_TEMPLATE_P(NODE) \
+ (TREE_CODE (NODE) == TEMPLATE_DECL \
+DECL_TEMPLATE_RESULT (NODE) !=
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
http://translationproject.org/latest/gcc/de.po
(This file, 'gcc-4.8.0.de.po', has just
On 04/01/2013 01:11 PM, Paolo Carlini wrote:
We have an ICE for g++.dg/template/qualttp17.C. Is this something we
want to further investigate now or shall I just leave the check in?
Leave the check. The patch is OK.
Jason
Hi all,
When doing namelist reads, nml_read_obj calls itself recursively to read through
arrays. Short lists are allowed so we have to have a way to detect if we have a
short read or a real error.
We do this by flagging errors and then backing out of the read and checking to
see if what we
Am 01.04.2013 20:33, schrieb Jerry DeLisle:
With this particular bug, nml_read_obj was clearing the error flag itself with
the read so that rather then bailing out, it tried to continue reading data
until it was done, then the subsequent read failed looking for a valid name,
which had been
I'm not sure what this is supposed to do. How is pat == target ever
going to be true when ANY_RETURN_P (pat) is true? Isn't target supposed
to be a CODE_LABEL or NULL? What am I missing?
The simple_return change from Bernd. The JUMP_LABEL of a JUMP_INSN is now
either a CODE_LABEL or a
On 03/29/13 16:57, Iyer, Balaji V wrote:
Hello Joseph, Aldy et al.,
I reworded couple comments (e.g changed builtin with built-in, etc) and
added a header comment to the c-array-notation.c that explains the overall
process. I am attaching a fixed patch.
Ok, this latest patch that
On Sun, Mar 31, 2013 at 12:13 AM, Jason Merrill ja...@redhat.com wrote:
On 03/29/2013 10:56 PM, Gabriel Dos Reis wrote:
int wanted = num_template_headers_for_class (ctx);
I think you want to add one to wanted if decl is a primary template.
OK but I am a little bit dense here: why is
On 04/01/2013 04:53 PM, Gabriel Dos Reis wrote:
On Sun, Mar 31, 2013 at 12:13 AM, Jason Merrill ja...@redhat.com wrote:
On 03/29/2013 10:56 PM, Gabriel Dos Reis wrote:
int wanted = num_template_headers_for_class (ctx);
I think you want to add one to wanted if decl is a primary
On 03/29/13 16:57, Iyer, Balaji V wrote:
+bool
+find_rank (location_t loc, tree orig_expr, tree array, bool ignore_builtin_fn,
+ size_t *rank)
+{
+ tree ii_tree;
Balaji, I believe what Joseph meant with saving the location_t is so we
can give meaningful error messages when
Hi all,
here is a small patch which does two things:
1) It fixes the ICE in the subject line (in a rather obvious way).
2) It warns about alternate-return arguments (which is an obsolescent
feature), and adds -std=legacy to some test cases to suppress the
warning.
Regarding the second point, one
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Aldy Hernandez
Sent: Monday, April 01, 2013 5:02 PM
To: Iyer, Balaji V
Cc: 'Joseph Myers'; 'gcc-patches'
Subject: Re: [patch] cilkplus: Array notation for C patch
On
On Mon, Apr 1, 2013 at 3:58 PM, Jason Merrill ja...@redhat.com wrote:
On 04/01/2013 04:53 PM, Gabriel Dos Reis wrote:
On Sun, Mar 31, 2013 at 12:13 AM, Jason Merrill ja...@redhat.com wrote:
On 03/29/2013 10:56 PM, Gabriel Dos Reis wrote:
int wanted = num_template_headers_for_class
We try to resolve types at template definition time if expressions don't
depend on template parameters, but this testcase shows a case of
dependency we weren't considering: the bounds of an array can depend on
the length of the initializer.
Tested x86_64-pc-linux-gnu, applying to 4.7, 4.8,
1 - 100 of 111 matches
Mail list logo
