Re: Is this power gcc bug?
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 contradictory options. -m32 is *not* LP64. The left shift count is 32, it is actually less than the width of unsigned long 64. Nope, unsigned long is 32 bits for -m32. -- Alan Modra Australia Development Lab, IBM
Trying to find a link for information about parsing template parameters and the problem
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. Please provide me with the link. Alec
Re: Trying to find a link for information about parsing template parameters and the problem
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 yielded people asking questions about errors where occurs. Please provide me with the link. I'm not sure this kind of message really belongs on the gcc@gcc.gnu.org mailing list, which is for issues related to the development of GCC. I understand that you are looking at rewriting the C++ parser (why?) but this is just a basic C++ question, not a GCC issue. 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 expects. Note that this issue is fixed in C++11. Ian
increasing testsuite-errors when optimizing for amdfam10/bdver2
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 nervous and after some additional errors when running the glibc-2.17-testsuite I've refused to use this optimisation as default on my system. The results might be interesting for the gcc-developer-community and I've mailed four results with different set of '--with-arch' and '--with-tune' to gcc-testresu...@gcc.gnu.org from stock gcc-4.8.0. I've set '--build=x86_64-winnix-linux-gnu' just to make it easier to search the archive for this specific results (results include the complete set of relevant libs/tools). Basic flags for every compile/test-run: --build=x86_64-winnix-linux-gnu --enable-languages=c,c++ --enable-shared --prefix=/usr --enable-multilib=no optimization for phenom2 (I've used since I've replaced my Athlon-FX): --with-arch=amdfam10 --with-tune=amdfam10 soft-optimization for bdver2 which is the current configuration I use on my system (no additional errors in glibc-2.17: --with-arch=amdfam10 --with-tune=bdver2 optimization for bdver2: --with-arch=bdver2 --with-tune=bdver2 The number of additional errors is always increasing. Mostly errors in scan-assembler and scan-tree-dump (maybe wrong expections in the tests?) but with arch=bdver2 I see an increasing number of execution-tests failing. Surprisingly (at least for me) the difference is only visible in the gcc-testsuite and doesn't harm other languages. I've done some work to ensure errors are not related to the system-setup and maybe it's of interest what I've learned during this process: gcc.dg/guality/vla-1.c and vla-2.c depends on the gdb-version. Fails with stock gdb-7.5.1 (also tested prerelease gdb-7.5.91) and don't fail with gdb-patches from opensuse (fedora-patches works also). Using tcl8.6.0 as base for expect/dejagnu doesn't currently work, at least not with the gcc-testsuite. Please note that this is not a regression and that gcc-4.7.x gives very similar results. Thank you for listening and all the good work I apreciate since 20 years with all sorts of cpu's and operating-systems gcc supports! best regards winfried
Re: Trying to find a link for information about parsing template parameters and the problem
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 cannot find the link!
Searching for it has yielded people asking questions about errors where
occurs.
Please provide me with the link.
I'm not sure this kind of message really belongs on the
gcc@gcc.gnu.org mailing list, which is for issues related to the
development of GCC. I understand that you are looking at rewriting
the C++ parser (why?) but this is just a basic C++ question, not a GCC
issue.
An exercise mainly, the goal would be to better facilitate error report
generation, by creating (perhaps with a flag) some sort of AST that may
be dumped or exported. Exporting headers in this form (and importing
later) done with a flag of course. Bringing the parser and symbol table
closer together.
Some things can just be better parsed going from right to left, ; end a
statement and { } form lovely blocks, reading from right to left
shouldn't be too bad at all, nor would perhaps threading complication
(this is just a thought, I know compiling is a task that lends itself to
being done in parallel rather nicely), with this format too you could
perhaps (again with flags) store 'notes' about a function with the hash
of the tokens that make it up, save recompiling an entire file. This
data wouldn't go inside the object file, and these are just some thoughts.
Having such a note file could be useful if any compiler instance can
write to it (if the thing it is notes of is being used) to build a
program-wide callgraph while compiling, I suspect LTO does this already
within the object file though.
If IDEs could make use of this file it'd be even better. I understand
I've gotten quite far from why the parser now.
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 expects.
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 evaluation!
the article spoke about GCC, I'm sure it was under the gnu domain
gah! I wish I could recall!
Note that this issue is fixed in C++11.
Ian
Alec
Re: Trying to find a link for information about parsing template parameters and the problem
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 expects. 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 evaluation! the article spoke about GCC, I'm sure it was under the gnu domain gah! I wish I could recall! Probably http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html
Re: Trying to find a link for information about parsing template parameters and the problem
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 evaluation! the article spoke about GCC, I'm sure it was under the gnu domain gah! I wish I could recall! Probably http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html It is! Thanks once again Jonathan. Alec
Re: [Patch, testsuite] Add missing -gdwarf-2 flag in debug/dwarf2 testcase
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
Re: [Patch, testsuite] Add missing -gdwarf-2 flag in debug/dwarf2 testcase
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 it for DWARF 1 in GCC 3.4. I like that.
[Bug target/55583] Extended shift instruction on x86-64 is not used, producing unoptimal code
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 posted comment #4. This is just to show the idea, it doesn't handle many cases, and the length_immediate value was randomly filled just to let it compile.
[Bug c/52952] Wformat location info is bad (wrong column number)
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(%) . R(*) d);
would
BTW, your testcase does not work for me and confuses GCC:
/home/manuel/loc_offset.c:7:21: error: unterminated raw string
__builtin_printf (R(%) R(*d) );
^
/home/manuel/loc_offset.c:7:3: error: expected expression at end of input
__builtin_printf (R(%) R(*d) );
^
/home/manuel/loc_offset.c:7:3: error: expected declaration or statement at end
of input
It is also very unclear to me how to re-process such a token stream in order to
find out the real location+offset.
A further issue is that for:
#define FORMAT .*d
#include stdio.h
void f() {
printf(
%
FORMAT);
}
the token representing % is overriden when we call cpp_get_token next time:
@@ -1003,10 +1004,13 @@ lex_string (const cpp_token *tok, tree *
concatenation. It is 'true' if we have seen an '@' before the
current string, and 'false' if not. We must see exactly one or
zero '@' before each string. */
bool objc_at_sign_was_seen = false;
+ // This token is overwritten! How can that happen?
+ const cpp_token *prev_tok = tok;
+
retry:
tok = cpp_get_token (parse_in);
switch (tok-type)
{
case CPP_PADDING:
so prev_tok above may or may not change by the call of cpp_get_token.
[Bug c/52952] Wformat location info is bad (wrong column number)
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 is obsolete|| Attachment #29755|0 |1 is obsolete|| --- Comment #23 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-01 14:20:16 UTC --- Created attachment 29765 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29765 add locations and offsets to format warnings + loc_token hash This patch works perfect for simple sequences of plain strings and when the whole format string comes from a macro expansion.
[Bug c/52952] Wformat location info is bad (wrong column number)
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)
[Bug tree-optimization/56799] New: Runfail after r197060+r197082.
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 Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ysrum...@gmail.com Created attachment 29766 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29766 Testcase to reproduce the failure. We got Runfail on the attached test-case which was extracted form 254.gap (spec2000). The problem looks like a check on type widening was missed in this fix.
[Bug tree-optimization/56799] Runfail after r197060+r197082.
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.
[Bug fortran/56800] New: [fortran-dev Regression] move_alloc_13.f90 failure
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: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org The move_alloc_13 failure on the fortran-dev branch can be reduced to a wrong setting of sm to zero in: ig25@linux-fd1f:~/Krempel/Branch cat mv.f90 type t end type t type, extends(t) :: t2 integer :: a end type t2 class(t), allocatable :: y(:), z(:) allocate(y(1), source=[t2(2)]) end ig25@linux-fd1f:~/Krempel/Branch gfortran -fdump-tree-original mv.f90 [...] __builtin_memset (y._data.base_addr, 0, 4); y._data.dtype = 41; y._data.dim[0].lower_bound = 1; y._data.dim[0].extent = 2 - y._data.dim[0].lower_bound; y._data.dim[0].sm = 0; y._data.offset = -1;
[Bug middle-end/52436] BIT_FIELD_REF MEM_REF should be canonicalized for non-bitfield accesses
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 gcc.dg/vect/nodump-forwprop-22.c (although we might consider that it is forwprop that is too weak). Also, it doesn't put exactly __m128i* in the MEM_REF but instead long long* (s_1m* would be easy as well, but I don't know what property of __m128i makes it the right type so I can't teach that to the compiler). The forwprop bit is for PR55266 and not strictly necessary here.
[Bug fortran/50269] Wrongly rejects element of assumed-shape array in C_LOC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50269 Rich Townsend townsend at astro dot wisc.edu changed: What|Removed |Added CC||townsend at astro dot ||wisc.edu --- Comment #5 from Rich Townsend townsend at astro dot wisc.edu 2013-04-01 15:30:54 UTC --- (In reply to comment #4) FIXED on the 4.9 trunk. Is this going to be ported back to earlier releases? It's kind of a biggie for me...
[Bug fortran/56500] [OOP] IMPLICIT CLASS(...) wrongly rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56500 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from janus at gcc dot gnu.org 2013-04-01 15:34:40 UTC --- Fixed with r197306: http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=197306 Closing.
[Bug c/56798] ICE in patch_jump_insn, at cfgrtl.c:1238
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56798 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-04-01 CC|stevenb.gcc at gmail dot| |com | AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug c/56798] ICE in patch_jump_insn, at cfgrtl.c:1238
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56798 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Steven Bosscher steven at gcc dot gnu.org 2013-04-01 15:51:31 UTC --- Fixed.
[Bug libitm/56801] New: Internal Compiler Error when compiling relaxed transaction
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: UNCONFIRMED
Severity: normal
Priority: P3
Component: libitm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sp...@cse.lehigh.edu
I am receiving the following error:
internal compiler error: in expand_call_tm, at trans-mem.c:2280
When compiling a simple program. The following test case is derived from
memcached 1.4.13:
// filename: testcase.c
#include stdio.h
#include stdlib.h
__attribute__((transaction_callable))
void slabs_adjust_mem_requested(unsigned int id, size_t old, size_t ntotal);
typedef struct {
unsigned int size;
unsigned int perslab;
void *slots;
unsigned int sl_curr;
void *end_page_ptr;
unsigned int end_page_free;
unsigned int slabs;
void **slab_list;
unsigned int list_size;
unsigned int killing;
size_t requested;
} slabclass_t;
static slabclass_t slabclass[(200 + 1)];
static int power_largest;
void slabs_adjust_mem_requested(unsigned int id, size_t old, size_t ntotal)
{
__transaction_relaxed {
slabclass_t *p;
if (id 1 || id power_largest) {
fprintf(stderr, Internal error! Invalid slab class\n);
abort();
}
p = slabclass[id];
p-requested = p-requested - old + ntotal;
}
}
Compilation line:
gcc -std=gnu11 -g -O2 -fgnu-tm -pthread -c testcase.c -o testcase.o
[Bug libitm/56801] Internal Compiler Error when compiling relaxed transaction
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 -v. This is a standard 64-bit Ubuntu platform: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.2-2ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1)
[Bug libfortran/51119] MATMUL slow for large matrices
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 --- Comment #11 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-04-01 15:58:52 UTC --- A bit like PR 37131 (but I don't want to lose either audit trail).
[Bug debug/45882] No debug info for vars depending on unused parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45882 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #4 from Steven Bosscher steven at gcc dot gnu.org 2013-04-01 16:39:05 UTC --- Jakub, do you remember what this change was necessary for: * rtl.def (ENTRY_VALUE): Change format from e to 0. I'm reviewing the 0 fields and I don't understand why ENTRY_VALUE has this 0 instead of e. Hope you remember :-)
[Bug other/56802] New: --with-build-sysroot does not affect library search directories
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: UNCONFIRMED Severity: major Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: e515...@rmqkr.net I would like to to build gcc with a glibc other than the used by the build system and compiler. The resulting compiler is installed to a host that has the glibc I am building against and everything else (binutils) in the regular /usr/. I am configuring gcc with --enable-languages=c,c++ --disable-multilib --with-build-sysroot=/tmp/sysrootd, with my target glibc copied to /tmp/sysrootd. Building works but linking the second stage fails, with ld not being able to find crti.o. I think with-build-sysroot should affect library search directories.
[Bug other/56802] --with-build-sysroot does not affect library search directories
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.
[Bug fortran/56800] [fortran-dev Regression] move_alloc_13.f90 failure
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).
[Bug other/56802] --with-build-sysroot does not affect library search directories
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 already.
[Bug other/56802] --with-build-sysroot does not affect library search directories
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.
[Bug fortran/56731] [4.7 Regression] [OOP] ICE on (wrongly) referencing polymorphic array in select type
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 must not have the ALLOCATABLE attribute at (1) That error message was apparently fixed for CLASS components (PR53191) with this commit: http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=187192 Not sure if it's worth backporting though.
[Bug other/56802] --with-build-sysroot does not affect library search directories
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 versions of glibc, though. The different version of glibc is what causes it to be cross compiling.
[Bug other/56802] --with-build-sysroot does not affect library search directories
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 and target use different versions of glibc, though. The different version of glibc is what causes it to be cross compiling. Thanks, that makes sense. How would the host and target triplets for the two cross compiler look like - after all, I am on the same system. Is there any way to prevent this dance? I do not care about bootstrapping at this point, I just need a working compiler for the new glibc.
[Bug other/56802] --with-build-sysroot does not affect library search directories
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 for the new glibc. How about disabling bootstrapping and forcing to link the new glibc via --with-stage1-ldflags?
[Bug fortran/56800] [fortran-dev Regression] move_alloc_13.f90 failure
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 gfc_conv_descriptor_sm_set. Additionally, one could directly set gfc_conv_descriptor_extent_set (matching the current size variable) instead of using gfc_conv_descriptor_ubound_set. The only difficulty is to implement it such that the overflow algorithm works.
[Bug debug/45882] No debug info for vars depending on unused parameter
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 RTL as a black box, mostly when you want to look at the operand is either for rtx_equal_p and similar functions, or when creating those or when the debug info is emitted from it. If ENTRY_VALUE's operand is e rather than 0, e.g. various RTL passes would consider the there referenced hard register (or memory) to be live at that point, or used, etc., but it actually isn't used.
[Bug fortran/56803] New: EOF with namelist read give INTERNAL error instead of END OF FILE error
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 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: jvdeli...@gcc.gnu.org Blocks: 56744 Follow up to PR56660 comment 19, see also PR56660. The following program - which lacks a / - gives with GCC 4.1: Fortran runtime error: End of file But with GCC 4.3 to 4.9 it gives: Fortran runtime error: Internal namelist read error Expected: END of file. Which I also get with NAG, Pathscale, PGI and Crayftn. implicit none integer :: ii namelist /nml/ ii open(99, status=scratch) write(99,'(a)') nml ii=55 rewind(99) read(99, nml=nml) print *, ii end
[Bug c++/56794] [4.7/4.8/4.9 Regression] C++11 Error in range-based for with parameter pack array
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 CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/56793] ICE with scoped enum
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 CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug fortran/56803] EOF with namelist read give INTERNAL error instead of END OF FILE error
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 (unit = 99, file = '/tmp/gfortrantmp5qfaGE') Fortran runtime error: End of file
[Bug fortran/56803] EOF with namelist read give INTERNAL error instead of END OF FILE error
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 CC||burnus at gcc dot gnu.org Resolution||DUPLICATE --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-01 20:26:22 UTC --- Okay - let's mark it then as duplicate. *** This bug has been marked as a duplicate of bug 56786 ***
[Bug libfortran/56786] [4.6/4.7/4.8/4.9 Regression] Namelist read fails with designators containing embedded spaces
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. ***
[Bug libfortran/56786] [4.6/4.7/4.8/4.9 Regression] Namelist read fails with designators containing embedded spaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56786 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-01 20:27:31 UTC --- (In reply to comment #2) *** Bug 56803 has been marked as a duplicate of this bug. *** Author: jvdelisle Date: Sun Mar 31 20:37:19 2013 New Revision: 197291 URL: http://gcc.gnu.org/viewcvs?rev=197291root=gccview=rev Log: 2013-03-31 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/56786 * gfortran.dg/namelist_81.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/namelist_81.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug libfortran/56786] [4.6/4.7/4.8/4.9 Regression] Namelist read fails with designators containing embedded spaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56786 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |4.6.4 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-01 20:29:46 UTC --- (In reply to comment #2) *** Bug 56803 has been marked as a duplicate of this bug. *** That bug has the following test case. We should consider adding it as well. In addition, the compiler should report END of file and not an error - hence, libgfortran is not according the standard by failing in the wrong way: implicit none integer :: ii namelist /nml/ ii open(99, status=scratch) write(99,'(a)') nml ii=55 rewind(99) read(99, nml=nml, end=77, err=90) print *, ii stop 'OK - vendor extension: successful READ w/o /' 77 stop 'OK - END of FILE hit' 90 call abort() ! Wrong end
[Bug c++/56772] placement new operator does not work inside function template for array types.
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 Last reconfirmed||2013-04-01 CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug fortran/56660] Fails to read NAMELIST with certain form array syntax
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: 2013-04-01 Jerry DeLisle jvdeli...@gcc.gnu.org PR libfortran/56660 * io/list_read.c (nml_read_obj): Do not reset the read error flag inside nml_read_obj. If the read error flag is found set just exit. Fix some whitespace on comments. (nml_read_obj_data): Reset the read error flag before the first call to nml_read_object. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c
[Bug fortran/56660] Fails to read NAMELIST with certain form array syntax
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: 2013-04-01 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/56660 * gfortran.dg/namelist_82.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/namelist_82.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/45917] inaccessible types allowed as template argument in nested-name-specifier
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 Resolution||FIXED Target Milestone|--- |4.9.0 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2013-04-01 21:04:03 UTC --- Fixed for 4.9.
[Bug c++/55241] [C++11] diagnostics show sizeof...(T) as sizeof(T...)
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 Resolution||FIXED Target Milestone|--- |4.9.0 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2013-04-01 21:04:36 UTC --- Fixed for 4.9.
[Bug c++/55931] [C++11] Constexpr member function inside a static member is not working
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 Resolution||FIXED Target Milestone|--- |4.9.0 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org 2013-04-01 21:05:51 UTC --- Fixed for 4.9.
[Bug c++/55240] [c++0x] ICE on non-static data member initialization using 'auto' variable from containing function
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 Resolution||FIXED Target Milestone|--- |4.9.0 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2013-04-01 21:06:20 UTC --- Fixed for 4.9.
[Bug c++/55017] [DR 1051] [C++11] Rvalue-reference member should cause copy constructor to be deleted, but still declared
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 Resolution||FIXED Target Milestone|--- |4.9.0 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2013-04-01 21:06:42 UTC --- Fixed for 4.9.
[Bug c++/54946] ICE on template parameter from cast char-pointer in C++11 constexpr struct
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 Resolution||FIXED Target Milestone|--- |4.9.0 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2013-04-01 21:07:04 UTC --- Fixed for 4.9.
[Bug c++/54532] [C++0x][constexpr] internal error when initializing static constexpr with pointer to non-static member variable
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 Resolution||FIXED Target Milestone|--- |4.9.0 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2013-04-01 21:07:42 UTC --- Fixed for 4.9.
[Bug c++/56794] [4.7/4.8/4.9 Regression] C++11 Error in range-based for with parameter pack array
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 Resolution||FIXED Target Milestone|--- |4.7.3 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2013-04-01 21:22:04 UTC --- Fixed for 4.7.3/4.8.1/4.9.
[Bug c++/56793] ICE with scoped enum
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 Resolution||FIXED Target Milestone|--- |4.8.1 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2013-04-01 21:22:22 UTC --- Fixed for 4.8.1/4.9.
[Bug c++/56772] placement new operator does not work inside function template for array types.
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 Resolution||FIXED Target Milestone|--- |4.8.1 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2013-04-01 21:22:40 UTC --- Fixed for 4.8.1/4.9.
[Bug fortran/56800] [fortran-dev Regression] move_alloc_13.f90 failure
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 - but it needs some clean up in the bottom part. As I run out of time, I attach it here.
[Bug c++/55951] [4.8/4.9 Regression] ICE in check_array_designated_initializer, at cp/decl.c:4785
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55951 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2013-04-01 21:36:28 UTC --- Fixed 4.8.1 too.
[Bug lto/56804] New: lto1: internal compiler error: bytecode stream: found non-null terminated string
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
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vcho...@gmail.com
bash-4.1$ x86_64-w64-mingw32-gcc -I. -flto -c -save-temps -o lto-bug.o
lto-bug.c
lto-bug.c: In function 'check_vpx_codec_dec_init_ver':
lto-bug.c:3:50: warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
long check_vpx_codec_dec_init_ver(void) { return (long)
vpx_codec_dec_init_ver; }
^
bash-4.1$ x86_64-w64-mingw32-gcc -L. -flto -save-temps -o lto-bug.exe lto-bug.o
-lvpx
lto1: internal compiler error: bytecode stream: found non-null terminated
string
0xa58590 bp_unpack_string(data_in*, bitpack_d*)
../../gcc-4_9-trunk/gcc/data-streamer-in.c:112
0x7da427 unpack_ts_translation_unit_decl_value_fields
../../gcc-4_9-trunk/gcc/tree-streamer-in.c:383
0x7da427 unpack_value_fields
../../gcc-4_9-trunk/gcc/tree-streamer-in.c:465
0x7dafcd streamer_read_tree_bitfields(lto_input_block*, data_in*, tree_node*)
../../gcc-4_9-trunk/gcc/tree-streamer-in.c:510
0x5feb03 lto_read_tree
../../gcc-4_9-trunk/gcc/lto-streamer-in.c:1012
0x5feb03 lto_input_tree(lto_input_block*, data_in*)
../../gcc-4_9-trunk/gcc/lto-streamer-in.c:1082
0x7d8344 lto_input_ts_decl_minimal_tree_pointers
../../gcc-4_9-trunk/gcc/tree-streamer-in.c:641
0x7d8344 streamer_read_tree_body(lto_input_block*, data_in*, tree_node*)
../../gcc-4_9-trunk/gcc/tree-streamer-in.c:981
0x5feb11 lto_read_tree
../../gcc-4_9-trunk/gcc/lto-streamer-in.c:1015
0x5feb11 lto_input_tree(lto_input_block*, data_in*)
../../gcc-4_9-trunk/gcc/lto-streamer-in.c:1082
0x7d84ee lto_input_ts_type_common_tree_pointers
../../gcc-4_9-trunk/gcc/tree-streamer-in.c:765
0x7d84ee streamer_read_tree_body(lto_input_block*, data_in*, tree_node*)
../../gcc-4_9-trunk/gcc/tree-streamer-in.c:999
0x5feb11 lto_read_tree
../../gcc-4_9-trunk/gcc/lto-streamer-in.c:1015
0x5feb11 lto_input_tree(lto_input_block*, data_in*)
../../gcc-4_9-trunk/gcc/lto-streamer-in.c:1082
0x7d7f19 lto_input_ts_common_tree_pointers
../../gcc-4_9-trunk/gcc/tree-streamer-in.c:601
0x7d7f19 streamer_read_tree_body(lto_input_block*, data_in*, tree_node*)
../../gcc-4_9-trunk/gcc/tree-streamer-in.c:972
0x5feb11 lto_read_tree
../../gcc-4_9-trunk/gcc/lto-streamer-in.c:1015
0x5feb11 lto_input_tree(lto_input_block*, data_in*)
../../gcc-4_9-trunk/gcc/lto-streamer-in.c:1082
0x41f69f lto_read_decls
../../gcc-4_9-trunk/gcc/lto/lto.c:2086
0x41f69f lto_file_finalize
../../gcc-4_9-trunk/gcc/lto/lto.c:2339
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
lto-wrapper: x86_64-w64-mingw32-gcc returned 1 exit status
[Leaving LTRANS lto-bug.exe.ltrans.out]
[Leaving LTRANS /tmp/cc2HMJtw.args]
/home/slave/local/xmingw-4_9-trunk-w64-seh/lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld:
lto-wrapper failed
collect2: error: ld returned 1 exit status
bash-4.1$ cat lto-bug.c
#include vpx/vpx_decoder.h
#include vpx/vp8dx.h
long check_vpx_codec_dec_init_ver(void) { return (long) vpx_codec_dec_init_ver;
}
int main(void) { return 0; }
[Bug lto/56804] lto1: internal compiler error: bytecode stream: found non-null terminated string
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
[Bug fortran/50269] Wrongly rejects element of assumed-shape array in C_LOC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50269 --- Comment #6 from Rich Townsend townsend at astro dot wisc.edu 2013-04-01 22:24:35 UTC --- (In reply to comment #4) FIXED on the 4.9 trunk. Are we sure? When running the code example given in comment #1, I get a segfault. Moreover, the following subroutine won't compile when using the '-std=f2008' flag: subroutine test_contig (a) use ISO_C_BINDING real, intent(in), contiguous, target :: a(:) type(C_PTR) :: b b = C_LOC(a) end subroutine test_contig The error message is: test_contig.f90:9.12: b = C_LOC(a) 1 Error: TS 29113: Noninteroperable array at (1) as argument to C_LOC: Only explicit-size and assumed-size arrays are interoperable My understanding of the F2008 standard is that assumed-shape arrays with the contiguous attribute are interoperable -- hence, I'm not sure this error message is correct. If I change the std flag to f2008ts, then the routine compiles OK; but the TS extension shouldn't be required here. gfortran -v: Using built-in specs. COLLECT_GCC=/Applications/madsdk/bin/gfortran.exec COLLECT_LTO_WRAPPER=/Applications/madsdk/libexec/gcc/x86_64-apple-darwin11.4.2/4.9.0/lto-wrapper Target: x86_64-apple-darwin11.4.2 Configured with: ./configure CC='gcc -D_FORTIFY_SOURCE=0' --build=x86_64-apple-darwin11.4.2 --prefix=/Applications/madsdk --with-gmp=/Applications/madsdk --with-mpfr=/Applications/madsdk --with-mpc=/Applications/madsdk --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.9.0 20130401 (experimental) (GCC)
[Bug lto/56804] lto1: internal compiler error: bytecode stream: found non-null terminated string
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
[Bug debug/56805] New: DW_AT_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)
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
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jan.sm...@alcatel-lucent.com
typedef struct
{
char b[4];
} some_typedef_name;
typedef some_typedef_name joske;
int main()
{
return 0;
}
Compiled with :
-gdwarf-4 -fno-var-tracking-assignments -fno-eliminate-unused-debug-types
-fdebug-types-section
Contents of the .debug_types section:
Compilation Unit @ offset 0x0:
Length:0x4f (32-bit)
Version: 4
Abbrev Offset: 0
Pointer Size: 4
Signature: 86cb53f6d82bc2c9
Type Offset: 0x1d
017: Abbrev Number: 1 (DW_TAG_type_unit)
18 DW_AT_language: 4(C++)
19 DW_AT_stmt_list : 0x0
11d: Abbrev Number: 2 (DW_TAG_structure_type)
1e DW_AT_byte_size : 4
1f DW_AT_decl_file : 1
20 DW_AT_decl_line : 2
21 DW_AT_linkage_name: (indirect string, offset: 0x0):
17some_typedef_name
25 DW_AT_sibling : 0x34
229: Abbrev Number: 3 (DW_TAG_member)
2a DW_AT_name: b
2c DW_AT_decl_file : 1
2d DW_AT_decl_line : 3
2e DW_AT_type: 0x34
32 DW_AT_data_member_location: 0
134: Abbrev Number: 4 (DW_TAG_array_type)
35 DW_AT_type: 0x44
39 DW_AT_sibling : 0x44
23d: Abbrev Number: 5 (DW_TAG_subrange_type)
3e DW_AT_type: 0x4b
42 DW_AT_upper_bound : 3
144: Abbrev Number: 6 (DW_TAG_base_type)
45 DW_AT_byte_size : 1
46 DW_AT_encoding: 6(signed char)
47 DW_AT_name: (indirect string, offset: 0x14): char
14b: Abbrev Number: 6 (DW_TAG_base_type)
4c DW_AT_byte_size : 4
4d DW_AT_encoding: 7(unsigned)
4e DW_AT_name: (indirect string, offset: 0x19): sizetype
Contents of the .debug_info section:
Compilation Unit @ offset 0x0:
Length:0x48 (32-bit)
Version: 4
Abbrev Offset: 0
Pointer Size: 4
0b: Abbrev Number: 7 (DW_TAG_compile_unit)
c DW_AT_producer: (indirect string, offset: 0x27): GNU C++ 4.8.0
10 DW_AT_language: 4(C++)
11 DW_AT_name: (indirect string, offset: 0x103): /tmp/dwarf.c
15 DW_AT_low_pc : 0x0
19 DW_AT_high_pc : 0x24
1d DW_AT_stmt_list : 0x0
121: Abbrev Number: 6 (DW_TAG_base_type)
22 DW_AT_byte_size : 4
23 DW_AT_encoding: 7(unsigned)
24 DW_AT_name: (indirect string, offset: 0x19): sizetype
128: Abbrev Number: 6 (DW_TAG_base_type)
29 DW_AT_byte_size : 1
2a DW_AT_encoding: 6(signed char)
2b DW_AT_name: (indirect string, offset: 0x14): char
12f: Abbrev Number: 8 (DW_TAG_subprogram)
30 DW_AT_external: 1
30 DW_AT_name: (indirect string, offset: 0x22): main
34 DW_AT_decl_file : 1
35 DW_AT_decl_line : 7
36 DW_AT_type: 0x44
3a DW_AT_low_pc : 0x0
3e DW_AT_high_pc : 0x24
42 DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
44 DW_AT_GNU_all_call_sites: 1
144: Abbrev Number: 9 (DW_TAG_base_type)
45 DW_AT_byte_size : 4
46 DW_AT_encoding: 5(signed)
47 DW_AT_name: int
without -fdebug-types-section (note the DW_AT_typedef for 'some_typedef_name'
and 'joske')
Contents of the .debug_info section:
Compilation Unit @ offset 0x0:
Length:0x85 (32-bit)
Version: 4
Abbrev Offset: 0
Pointer Size: 4
0b: Abbrev Number: 1 (DW_TAG_compile_unit)
c DW_AT_producer: (indirect string, offset: 0x2c): GNU C++ 4.8.0
10 DW_AT_language: 4(C++)
11 DW_AT_name: (indirect string, offset: 0x105): /tmp/dwarf.c
15 DW_AT_low_pc : 0x0
19 DW_AT_high_pc : 0x24
1d DW_AT_stmt_list : 0x0
121: Abbrev Number: 2 (DW_TAG_structure_type)
22 DW_AT_byte_size : 4
23 DW_AT_decl_file : 1
24 DW_AT_decl_line : 2
25 DW_AT_linkage_name: (indirect string, offset: 0x18):
17some_typedef_name
29 DW_AT_sibling : 0x38
22d: Abbrev Number: 3 (DW_TAG_member)
2e DW_AT_name: b
30 DW_AT_decl_file : 1
31 DW_AT_decl_line : 3
32 DW_AT_type: 0x38
36 DW_AT_data_member_location: 0
138: Abbrev Number: 4 (DW_TAG_array_type)
39 DW_AT_type: 0x4f
3d DW_AT_sibling : 0x48
241: Abbrev Number: 5 (DW_TAG_subrange_type)
42 DW_AT_type: 0x48
46 DW_AT_upper_bound : 3
148:
[Bug debug/56805] DW_AT_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)
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.
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 incrediball peter at axium dot co.nz changed: What|Removed |Added CC||peter at axium dot co.nz --- Comment #15 from incrediball peter at axium dot co.nz 2013-04-02 00:58:40 UTC --- I believe the discussion here is missing the point. Currently (at least with version 4.5 and ARM, which I am currently using) the situation is that the compiler generates broken code WITHOUT COMMENT when the address of something like an integer in a packed structure is assigned to a int* . Since the pointer type does not provide any information about the actual alignment of the integer, it is obviously impractical to fix when accessing the integer and we certainly do not want to have extra code inserted for handling the possibility that the int may not be aligned correctly. Therefore the compiler MUST see this as a type conflict and at least warn that the address of the member in a packed struct is incompatible with the pointer type. I have several projects which require the use of packed structures and I simply cannot rule out that that I have not at some point accidentally assigned the address of a member variable to a pointer. It would therefore be very handy if the compiler could point this out. -Wcast-align certainly doesn't do this.
[Bug other/48318] Memory access error by build/genhooks?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48318 Scott L. Burson Scott at sympoiesis dot com changed: What|Removed |Added CC||Scott at sympoiesis dot com --- Comment #9 from Scott L. Burson Scott at sympoiesis dot com 2013-04-02 01:58:21 UTC --- If anyone still cares, I figured out what this was, having run into it too. The clue is bad permissions for mapped region. A look at /proc/PID/maps confirms this: the region of genhooks that contains strcpy@@GLIBC_2.2.5 is mapped without execute permission. It appears that the openSUSE 11.4 version of ld is too old for recent versions of GCC. Installing binutils 2.23.2 has fixed the problem for me.
Re: [rtl, i386] vec_merge simplification
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 instead of INTVAL with it. And: + unsigned HOST_WIDE_INT mask = (HOST_WIDE_INT_1 n_elts) - 1; can be flagged as relying on undefined behavior (we fixed a bunch of cases a couple of years ago) so use: unsigned HOST_WIDE_INT mask = ((unsigned HOST_WIDE_INT) 1 n_elts) - 1; By the way, shouldn't this be: unsigned HOST_WIDE_INT mask = ((unsigned HOST_WIDE_INT) 2 (n_elts - 1)) - 1; so it doesn't cause undefined behavior for V64QI? -- Marc Glisse
Re: [PATCH, committed] Fix PR 45472
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 expressions so that the may_trap_p bit is preserved.
So the following patch was successfully tested on ia64 and x86-64, approved
by Alexander offline, committed to trunk. The patch needs backport to
other branches in about two weeks.
Andrey
PR middle-end/45472
gcc/
* sel-sched-ir.c (merge_expr): Also change vinsn of merged expr
when the may_trap_p bit of the exprs being merged differs.
Reorder tests for speculativeness in the logical and operator.
testsuite/
* gcc.dg/45472.c: New test.
Now backported to 4.7 and 4.6 with Jakub's patch for the sel-sched-ir.c
memory leak added.
Andrey
Index: gcc/ChangeLog
===
*** gcc/ChangeLog (revision 197298)
--- gcc/ChangeLog (revision 197299)
***
*** 1,6
--- 1,25
2013-04-01 Andrey Belevantsev a...@ispras.ru
Backport from mainline
+ 2013-02-27 Andrey Belevantsev a...@ispras.ru
+
+ PR middle-end/45472
+
+ * sel-sched-ir.c (merge_expr): Also change vinsn of merged expr
+ when the may_trap_p bit of the exprs being merged differs.
+ Reorder tests for speculativeness in the logical and operator.
+
+ Backport from mainline
+2013-03-05 Jakub Jelinek ja...@redhat.com
+
+ PR middle-end/56461
+ * sel-sched-ir.c (free_sched_pools): Release
+ succs_info_pool.stack[succs_info_pool.max_top] vectors too
+ if succs_info_pool.max_top isn't -1.
+
+ 2013-04-01 Andrey Belevantsev a...@ispras.ru
+
+ Backport from mainline
2012-02-19 Andrey Belevantsev a...@ispras.ru
PR middle-end/55889
Index: gcc/testsuite/gcc.dg/pr45472.c
===
*** gcc/testsuite/gcc.dg/pr45472.c (revision 0)
--- gcc/testsuite/gcc.dg/pr45472.c (revision 197299)
***
*** 0
--- 1,63
+ /* { dg-do compile { target powerpc*-*-* ia64-*-* x86_64-*-* } } */
+ /* { dg-options -O -fschedule-insns2 -fselective-scheduling2 } */
+
+ struct S
+ {
+ volatile long vl;
+ int i;
+ };
+ struct S s1, s2;
+
+ void
+ foo (int j, int c)
+ {
+ int i;
+ for (i = 0; i = j; i++)
+ {
+ if (c)
+ s2.vl += s1.vl;
+ s1 = s2;
+ }
+ }
+ /* { dg-do compile { target powerpc*-*-* ia64-*-* x86_64-*-* } } */
+ /* { dg-options -O -fschedule-insns2 -fselective-scheduling2 } */
+
+ struct S
+ {
+ volatile long vl;
+ int i;
+ };
+ struct S s1, s2;
+
+ void
+ foo (int j, int c)
+ {
+ int i;
+ for (i = 0; i = j; i++)
+ {
+ if (c)
+ s2.vl += s1.vl;
+ s1 = s2;
+ }
+ }
+ /* { dg-do compile { target powerpc*-*-* ia64-*-* x86_64-*-* } } */
+ /* { dg-options -O -fschedule-insns2 -fselective-scheduling2 } */
+
+ struct S
+ {
+ volatile long vl;
+ int i;
+ };
+ struct S s1, s2;
+
+ void
+ foo (int j, int c)
+ {
+ int i;
+ for (i = 0; i = j; i++)
+ {
+ if (c)
+ s2.vl += s1.vl;
+ s1 = s2;
+ }
+ }
Index: gcc/testsuite/ChangeLog
===
*** gcc/testsuite/ChangeLog (revision 197298)
--- gcc/testsuite/ChangeLog (revision 197299)
***
*** 1,3
--- 1,11
+ 2013-04-01 Andrey Belevantsev a...@ispras.ru
+
+ Backport from mainline
+ 2013-02-27 Andrey Belevantsev a...@ispras.ru
+
+ PR middle-end/45472
+ * gcc.dg/pr45472.c: New test.
+
2013-03-26 Richard Biener rguent...@suse.de
Backport from mainline
Index: gcc/sel-sched-ir.c
===
*** gcc/sel-sched-ir.c (revision 197298)
--- gcc/sel-sched-ir.c (revision 197299)
*** merge_expr (expr_t to, expr_t from, insn
*** 1862,1869
/* Make sure that speculative pattern is propagated into exprs that
have non-speculative one. This will provide us with consistent
speculative bits and speculative patterns inside expr. */
! if (EXPR_SPEC_DONE_DS (to) == 0
!EXPR_SPEC_DONE_DS (from) != 0)
change_vinsn_in_expr (to, EXPR_VINSN (from));
merge_expr_data (to, from, split_point);
--- 1862,1873
/* Make sure that speculative pattern is propagated into exprs that
have non-speculative one. This will provide us with consistent
speculative bits and speculative patterns inside expr. */
! if ((EXPR_SPEC_DONE_DS (from) != 0
! EXPR_SPEC_DONE_DS (to) == 0)
! /* Do likewise for volatile insns, so that we always retain
!the may_trap_p bit on the resulting expression. */
!
Re: Fix PR 56077
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 the binary negation for clarity. The patch was tested on x86-64, ia64, and ppc64 to be safe. The patch should be conservatively safe at this stage as it adds more flushes and thus more dependencies to the scheduler. The original test is fixed, but I don't know how to add the test checking assembly insns order to the testsuite. OK for trunk? Andrey 2012-02-22 Alexander Monakov amona...@ispras.ru Andrey Belevantsev a...@ispras.ru PR middle-end/56077 * sched-deps.c (sched_analyze_insn): When reg_pending_barrier, flush pending lists also on non-jumps. Now backported to 4.7 and 4.6. Andrey Index: gcc/ChangeLog === *** gcc/ChangeLog (revision 197296) --- gcc/ChangeLog (revision 197297) *** *** 1,3 --- 1,13 + 2013-04-01 Andrey Belevantsev a...@ispras.ru + + Backport from mainline + 2013-02-25 Andrey Belevantsev a...@ispras.ru + Alexander Monakov amona...@ispras.ru + + PR middle-end/56077 + * sched-deps.c (sched_analyze_insn): When reg_pending_barrier, + flush pending lists also on non-jumps. Adjust comment. + 2013-03-30 Gerald Pfeifer ger...@pfeifer.com * doc/invoke.texi (AVR Options): Tweak link for AVR-LibC user manual. Index: gcc/sched-deps.c === *** gcc/sched-deps.c(revision 197296) --- gcc/sched-deps.c(revision 197297) *** sched_analyze_insn (struct deps_desc *de *** 3262,3270 SET_REGNO_REG_SET (deps-reg_last_in_use, i); } ! /* Flush pending lists on jumps, but not on speculative checks. */ ! if (JUMP_P (insn) !(sel_sched_p () ! sel_insn_is_speculation_check (insn))) flush_pending_lists (deps, insn, true, true); reg_pending_barrier = NOT_A_BARRIER; --- 3262,3270 SET_REGNO_REG_SET (deps-reg_last_in_use, i); } ! /* Don't flush pending lists on speculative checks for !selective scheduling. */ ! if (!sel_sched_p () || !sel_insn_is_speculation_check (insn)) flush_pending_lists (deps, insn, true, true); reg_pending_barrier = NOT_A_BARRIER;
Re: [PATCH] Fix PR 55889
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 I've made a minimal patch that checks only for that case
using the same function from IRA and avoids it.
The patch fixes the test case on AIX as reported by David and also
bootstraps and tests fine on x86-64 and ia64, ok for trunk?
The second patch is restoring debug printing in the scheduler that was
accidentally broken, possibly by Steven's cleanups (now a pattern is
expected where an insn was previously). I will commit is as obvious
separately.
Andrey
2012-02-19 Andrey Belevantsev a...@ispras.ru
PR middle-end/55889
* sel-sched.c: Include ira.h.
(implicit_clobber_conflict_p): New function.
(moveup_expr): Use it.
* Makefile.in (sel-sched.o): Depend on ira.h.
Now backported this to 4.7 and 4.6.
Andrey
Index: gcc/ChangeLog
===
*** gcc/ChangeLog (revision 197297)
--- gcc/ChangeLog (revision 197298)
***
*** 1,6
--- 1,18
2013-04-01 Andrey Belevantsev a...@ispras.ru
Backport from mainline
+ 2012-02-19 Andrey Belevantsev a...@ispras.ru
+
+ PR middle-end/55889
+
+ * sel-sched.c: Include ira.h.
+ (implicit_clobber_conflict_p): New function.
+ (moveup_expr): Use it.
+ * Makefile.in (sel-sched.o): Depend on ira.h.
+
+ 2013-04-01 Andrey Belevantsev a...@ispras.ru
+
+ Backport from mainline
2013-02-25 Andrey Belevantsev a...@ispras.ru
Alexander Monakov amona...@ispras.ru
Index: gcc/sel-sched.c
===
*** gcc/sel-sched.c (revision 197297)
--- gcc/sel-sched.c (revision 197298)
*** along with GCC; see the file COPYING3.
*** 45,50
--- 45,51
#include rtlhooks-def.h
#include output.h
#include emit-rtl.h
+ #include ira.h
#ifdef INSN_SCHEDULING
#include sel-sched-ir.h
*** moving_insn_creates_bookkeeping_block_p
*** 2113,2118
--- 2114,2174
return TRUE;
}
+ /* Return true when the conflict with newly created implicit clobbers
+between EXPR and THROUGH_INSN is found because of renaming. */
+ static bool
+ implicit_clobber_conflict_p (insn_t through_insn, expr_t expr)
+ {
+ HARD_REG_SET temp;
+ rtx insn, reg, rhs, pat;
+ hard_reg_set_iterator hrsi;
+ unsigned regno;
+ bool valid;
+
+ /* Make a new pseudo register. */
+ reg = gen_reg_rtx (GET_MODE (EXPR_LHS (expr)));
+ max_regno = max_reg_num ();
+ maybe_extend_reg_info_p ();
+
+ /* Validate a change and bail out early. */
+ insn = EXPR_INSN_RTX (expr);
+ validate_change (insn, SET_DEST (PATTERN (insn)), reg, true);
+ valid = verify_changes (0);
+ cancel_changes (0);
+ if (!valid)
+ {
+ if (sched_verbose = 6)
+ sel_print (implicit clobbers failed validation, );
+ return true;
+ }
+
+ /* Make a new insn with it. */
+ rhs = copy_rtx (VINSN_RHS (EXPR_VINSN (expr)));
+ pat = gen_rtx_SET (VOIDmode, reg, rhs);
+ start_sequence ();
+ insn = emit_insn (pat);
+ end_sequence ();
+
+ /* Calculate implicit clobbers. */
+ extract_insn (insn);
+ preprocess_constraints ();
+ ira_implicitly_set_insn_hard_regs (temp);
+ AND_COMPL_HARD_REG_SET (temp, ira_no_alloc_regs);
+
+ /* If any implicit clobber registers intersect with regular ones in
+ through_insn, we have a dependency and thus bail out. */
+ EXECUTE_IF_SET_IN_HARD_REG_SET (temp, 0, regno, hrsi)
+ {
+ vinsn_t vi = INSN_VINSN (through_insn);
+ if (bitmap_bit_p (VINSN_REG_SETS (vi), regno)
+ || bitmap_bit_p (VINSN_REG_CLOBBERS (vi), regno)
+ || bitmap_bit_p (VINSN_REG_USES (vi), regno))
+ return true;
+ }
+
+ return false;
+ }
+
/* Modifies EXPR so it can be moved through the THROUGH_INSN,
performing necessary transformations. Record the type of transformation
made in PTRANS_TYPE, when it is not NULL. When INSIDE_INSN_GROUP,
*** moveup_expr (expr_t expr, insn_t through
*** 2245,2250
--- 2301,2317
if (!enable_schedule_as_rhs_p || !EXPR_SEPARABLE_P (expr))
return MOVEUP_EXPR_NULL;
+ /* When renaming a hard register to a pseudo before reload, extra
+dependencies can occur from the implicit clobbers of the insn.
+Filter out such cases here. */
+ if (!reload_completed REG_P (EXPR_LHS (expr))
+ HARD_REGISTER_P (EXPR_LHS (expr))
+ implicit_clobber_conflict_p (through_insn, expr))
+ {
+ if (sched_verbose = 6)
+ sel_print (implicit clobbers conflict detected, );
+ return MOVEUP_EXPR_NULL;
+ }
Re: [libitm,PATCH] Fix bootstrap due to __always_inline in libitm
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. (__calculate_memory_order, atomic_thread_fence, atomic_signal_fence, test_and_set, clear, store, load, exchange, compare_exchange_weak, compare_exchange_strong, fetch_add, fetch_sub, fetch_and, fetch_or, fetch_xor): Add __always_inline to force inlining. The problem is the he added the following to local_atomic #ifndef __always_inline #define __always_inline inline __attribute__((always_inline)) #endif whereas /usr/include/sys/cdefs.h on FreeBSD has the following #define__always_inline __attribute__((__always_inline__)) and hence misses the inline (plus libitm/common.h already has ALWAYS_INLINE for that purpose). First blush it seems to me that we should consistently use ALWAYS_INLINE in this file too. I am fixing this by adding an explicit inline to those cases where necessary. I did not add it to struct members, which are considered inline by default (and believe Andi's patch may have been a bit over- eager from that perspective). But not that inline isn't the same as always_inline... Paolo.
[wwwdocs] Remove redirected link to AMD x86-64 release
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: /cvs/gcc/wwwdocs/htdocs/readings.html,v retrieving revision 1.230 diff -u -3 -p -r1.230 readings.html --- readings.html 31 Mar 2013 21:15:48 - 1.230 +++ readings.html 1 Apr 2013 10:05:03 - @@ -147,7 +147,6 @@ Intelreg;64 and IA-32 Architectures Sof br /a href=http://www.agner.org/optimize/;http://www.agner.org/optimize//a br /a href=http://www.sandpile.org;www.sandpile.org:/a Christian Ludloff's technical x86 processor information. - br /a href=http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_104_857_875^2371,00.html;AMD's x86-64 architecture/a /li lii860
[Patch, testsuite] Fix sra-13.c for 16 bit int
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) +++ gcc/testsuite/gcc.dg/tree-ssa/sra-13.c (working copy) @@ -95,7 +95,7 @@ b = 0; gu1.b.l = 2000; s = bar (); - if (s != 2000) + if (s != (int)2000) __builtin_abort (); if (gu2.b.l != 2000) __builtin_abort ();
Re: [Patch, Fortran, OOP] PR 56500: IMPLICIT CLASS(...) wrongly rejected
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 standard allows it, so I guess we should better support it ;) The short patch attached here replaces all previous draft patches in the PR and simultaneously fixes both comment 0 and 1. Regtested on x86_64-unknown-linux-gnu. Ok for trunk? Cheers, Janus 2013-03-20 Janus Weil ja...@gcc.gnu.org PR fortran/56500 * symbol.c (gfc_set_default_type): Build class container for IMPLICIT CLASS. 2013-03-20 Janus Weil ja...@gcc.gnu.org PR fortran/56500 * gfortran.dg/implicit_class_1.f90: New.
Re: [Patch, Fortran, OOP] PR 56500: IMPLICIT CLASS(...) wrongly rejected
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
Re: [Patch, Fortran, OOP] PR 56500: IMPLICIT CLASS(...) wrongly rejected
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 Fortran standard allows it, so I guess we should better support it ;) The patch is OK. Regards Thomas
[PATCH] [MIPS] Support microMIPS HI/QI moves
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 (working copy)
@@ -4538,13 +4538,14 @@
})
(define_insn *movhi_internal
- [(set (match_operand:HI 0 nonimmediate_operand =d,d,d,m,*a,*d)
- (match_operand:HI 1 move_operand d,I,m,dJ,*d*J,*a))]
+ [(set (match_operand:HI 0 nonimmediate_operand =d,!u,d,!u,d,ZU,m,*a,*d)
+ (match_operand:HI 1 move_operand d,J,I,ZU,m,!u,dJ,*d*J,*a))]
!TARGET_MIPS16
(register_operand (operands[0], HImode)
|| reg_or_0_operand (operands[1], HImode))
{ return mips_output_move (operands[0], operands[1]); }
- [(set_attr move_type move,const,load,store,mtlo,mflo)
+ [(set_attr move_type move,const,const,load,load,store,store,mtlo,mflo)
+ (set_attr compression all,micromips,*,micromips,*,micromips,*,*,*)
(set_attr mode HI)])
(define_insn *movhi_mips16
@@ -4613,13 +4614,14 @@
})
(define_insn *movqi_internal
- [(set (match_operand:QI 0 nonimmediate_operand =d,d,d,m,*a,*d)
- (match_operand:QI 1 move_operand d,I,m,dJ,*d*J,*a))]
+ [(set (match_operand:QI 0 nonimmediate_operand =d,!u,d,!u,d,ZV,m,*a,*d)
+ (match_operand:QI 1 move_operand d,J,I,ZW,m,!u,dJ,*d*J,*a))]
!TARGET_MIPS16
(register_operand (operands[0], QImode)
|| reg_or_0_operand (operands[1], QImode))
{ return mips_output_move (operands[0], operands[1]); }
- [(set_attr move_type move,const,load,store,mtlo,mflo)
+ [(set_attr move_type move,const,const,load,load,store,store,mtlo,mflo)
+ (set_attr compression all,micromips,*,micromips,*,micromips,*,*,*)
(set_attr mode QI)])
(define_insn *movqi_mips16
[PATCH, libgomp, libatomic] Fix configure for systems without libpthread
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 * libatomic/configure.ac: Add test without -pthread -lpthread. * libgomp/configure.ac: Ditto. * libatomic/configure: Regenerate. * libgomp/configure: Regenerate. OK for trunk? -- Pavel Chupin Intel Corporation 0001-Fix-libatomic-and-libgomp-configure-for-systems-with.patch Description: Binary data
[PATCH, testsuite]: Fix FAIL: obj-c++.dg/try-catch-13.mm -fgnu-runtime (test for errors, line 12)
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 mainline?
Uros.
Index: obj-c++.dg/try-catch-13.mm
===
--- obj-c++.dg/try-catch-13.mm (revision 197296)
+++ obj-c++.dg/try-catch-13.mm (working copy)
@@ -22,7 +22,7 @@
typeof(q) k = 66;
some_func (j);
/* { dg-error invalid conversion { target *-*-* } 23 } */
-/* { dg-error initializing argument { target *-*-* } 12 } */
+/* { dg-message initializing argument { target *-*-* } 12 } */
some_func (k);
}
@catch (id exc) {
@@ -39,7 +39,7 @@
/* { dg-error invalid conversion { target *-*-* } 38 } */
/* The following is disabled as it is already checked above and the testsuites
seems
to count multiple different identical errors on the same line only once */
-/* dg-error initializing argument { target *-*-* } 12 */
+/* dg-message initializing argument { target *-*-* } 12 */
}
@catch (id exc) {
@throw;
@@ -54,7 +54,7 @@
/* { dg-error invalid conversion { target *-*-* } 53 } */
/* The following is disabled as it is already checked above and the testsuites
seems
to count multiple different identical errors on the same line only once */
-/* dg-error initializing argument { target *-*-* } 12 */
+/* dg-message initializing argument { target *-*-* } 12 */
some_func (k);
}
@catch (id exc) {
Re: [Patch, Fortran, OOP] PR 56500: IMPLICIT CLASS(...) wrongly rejected
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 standard allows it, so I guess we should better support it ;) The patch is OK. Thanks, Thomas and Jerry, for the almost simultaneous reviews :) I have committed the patch as r197306. Btw, is there a reason the commit is not being listed in the Bugzilla PR automatically? (Did this feature get lost in the last server upgrade, or have I just messed up the ChangeLog format?) Cheers, Janus
[patch] PR56798 (committed)
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) +++ cfgbuild.c (working copy) @@ -51,7 +51,7 @@ inside_basic_block_p (const_rtx insn) case CODE_LABEL: /* Avoid creating of basic block for jumptables. */ return (NEXT_INSN (insn) == 0 - || ! JUMP_TABLE_DATA_P (insn)); + || ! JUMP_TABLE_DATA_P (NEXT_INSN (insn))); case JUMP_INSN: case CALL_INSN:
Re: SLP for vectors
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 = TREE_INT_CST_LOW (TREE_OPERAND (exp, 2));
+ if (this_off % BITS_PER_UNIT)
+ return NULL_TREE;
+ byte_offset += this_off / BITS_PER_UNIT;
+ }
+ break;
[C++ Patch] Mini bunch of mini clean-ups
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 to
DECL_MEMBER_FUNCTION_P. Objections?
///
2013-04-01 Paolo Carlini paolo.carl...@oracle.com
* cp-tree.h (DECL_UNBOUND_CLASS_TEMPLATE_P): Remove.
(DECL_FUNCTION_TEMPLATE_P): Adjust.
* cxx-pretty-print.c (pp_cxx_nested_name_specifier,
pp_cxx_qualified_id): Use get_containing_scope.
* parser.c (cp_parser_class_head): Likewise.
* pt.c (push_template_decl_real): Likewise.
* decl2.c (import_export_decl): Use DECL_TEMPLOID_INSTANTIATION.
* pt.c (unify): Use CP_INTEGRAL_TYPE_P.
Index: cp-tree.h
===
--- cp-tree.h (revision 197302)
+++ cp-tree.h (working copy)
@@ -3730,14 +3730,10 @@ more_aggr_init_expr_args_p (const aggr_init_expr_a
#define DECL_TEMPLATE_TEMPLATE_PARM_P(NODE) \
(TREE_CODE (NODE) == TEMPLATE_DECL DECL_TEMPLATE_PARM_P (NODE))
-/* Nonzero if NODE is a TEMPLATE_DECL representing an
- UNBOUND_CLASS_TEMPLATE tree node. */
-#define DECL_UNBOUND_CLASS_TEMPLATE_P(NODE) \
- (TREE_CODE (NODE) == TEMPLATE_DECL !DECL_TEMPLATE_RESULT (NODE))
-
-#define DECL_FUNCTION_TEMPLATE_P(NODE) \
- (TREE_CODE (NODE) == TEMPLATE_DECL \
-!DECL_UNBOUND_CLASS_TEMPLATE_P (NODE) \
+/* Nonzero for a DECL that represents a function template. */
+#define DECL_FUNCTION_TEMPLATE_P(NODE) \
+ (TREE_CODE (NODE) == TEMPLATE_DECL\
+DECL_TEMPLATE_RESULT (NODE) != NULL_TREE \
TREE_CODE (DECL_TEMPLATE_RESULT (NODE)) == FUNCTION_DECL)
/* Nonzero for a DECL that represents a class template or alias
Index: cxx-pretty-print.c
===
--- cxx-pretty-print.c (revision 197302)
+++ cxx-pretty-print.c (working copy)
@@ -260,7 +260,7 @@ pp_cxx_nested_name_specifier (cxx_pretty_printer *
{
if (!SCOPE_FILE_SCOPE_P (t) t != pp-enclosing_scope)
{
- tree scope = TYPE_P (t) ? TYPE_CONTEXT (t) : DECL_CONTEXT (t);
+ tree scope = get_containing_scope (t);
pp_cxx_nested_name_specifier (pp, scope);
pp_cxx_template_keyword_if_needed (pp, scope, t);
pp_cxx_unqualified_id (pp, t);
@@ -308,7 +308,7 @@ pp_cxx_qualified_id (cxx_pretty_printer *pp, tree
default:
{
- tree scope = TYPE_P (t) ? TYPE_CONTEXT (t) : DECL_CONTEXT (t);
+ tree scope = get_containing_scope (t);
if (scope != pp-enclosing_scope)
{
pp_cxx_nested_name_specifier (pp, scope);
Index: decl2.c
===
--- decl2.c (revision 197302)
+++ decl2.c (working copy)
@@ -2572,8 +2572,7 @@ import_export_decl (tree decl)
else
comdat_p = true;
}
- else if (DECL_TEMPLATE_INSTANTIATION (decl)
- || DECL_FRIEND_PSEUDO_TEMPLATE_INSTANTIATION (decl))
+ else if (DECL_TEMPLOID_INSTANTIATION (decl))
{
/* DECL is an implicit instantiation of a function or static
data member. */
Index: parser.c
===
--- parser.c(revision 197302)
+++ parser.c(working copy)
@@ -18773,9 +18773,7 @@ cp_parser_class_head (cp_parser* parser,
for (scope = TREE_TYPE (type);
scope TREE_CODE (scope) != NAMESPACE_DECL;
- scope = (TYPE_P (scope)
- ? TYPE_CONTEXT (scope)
- : DECL_CONTEXT (scope)))
+ scope = get_containing_scope (scope))
if (TYPE_P (scope)
CLASS_TYPE_P (scope)
CLASSTYPE_TEMPLATE_INFO (scope)
Index: pt.c
===
--- pt.c(revision 197302)
+++ pt.c(working copy)
@@ -4803,9 +4803,7 @@ push_template_decl_real (tree decl, bool is_friend
/* Can happen in erroneous input. */
break;
else
- current = (TYPE_P (current)
-? TYPE_CONTEXT (current)
-: DECL_CONTEXT (current));
+ current = get_containing_scope (current);
}
/* Check that the parms are used in the appropriate qualifying scopes
@@ -16750,8 +16748,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
else if (same_type_p (TREE_TYPE (arg), tparm))
/* OK */;
else if ((strict UNIFY_ALLOW_INTEGER)
- (TREE_CODE (tparm) == INTEGER_TYPE
- || TREE_CODE (tparm) == BOOLEAN_TYPE))
+ CP_INTEGRAL_TYPE_P (tparm))
/* Convert the ARG to the type of PARM; the deduced non-type
Re: [C++ Patch] Mini bunch of mini clean-ups
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 still build a template with no result? PS: In my opinion we should also rename DECL_FUNCTION_MEMBER_P to DECL_MEMBER_FUNCTION_P. Objections? The current name makes it clearer (to me, anyway) that the macro assumes that we already know we're looking at a FUNCTION_DECL. Jason
Re: [C++ Patch] Mini bunch of mini clean-ups
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? That is, do we still build a template with no result? Honestly, I don't know, I followed DECL_TYPE_TEMPLATE_P, I can see what happens if I remove it... PS: In my opinion we should also rename DECL_FUNCTION_MEMBER_P to DECL_MEMBER_FUNCTION_P. Objections? The current name makes it clearer (to me, anyway) that the macro assumes that we already know we're looking at a FUNCTION_DECL. Ok, the subtlety wasn't clean to me looking at the other predicates and the comment. Let's leave it alone for now. Paolo.
Re: [C++ Patch] Mini bunch of mini clean-ups
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) != NULL_TREE\ Do we need the NULL_TREE check? That is, do we still build a template with no result? Honestly, I don't know, I followed DECL_TYPE_TEMPLATE_P, I can see what happens if I remove it... 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? Thanks, Paolo.
New German PO file for 'gcc' (version 4.8.0)
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 now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
Re: [C++ Patch] Mini bunch of mini clean-ups
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
[patch,libfortran] PR56660 Fails to read NAMELIST with certain form array syntax
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 error-ed on was a valid object name rather than data. This is
problematic for reading strings or logicals, since the data can look like names.
To resolve the problem, we use a line_buffer to hold reads as we look ahead and
if we find an error we rewind, bail out of the read, and proceed to the next
read cycle which looks for an object name followed by an = sign.
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 passed by.
The problem is resolved by moving the error flag reset outside nml_read_obj just
before the call to nml_read_obj. Also, we test the flag on entering
nml_read_obj, and if it is set, we bail out right away, a do nothing, until the
parent nml_read_obj finishes its loops.
Regression tested on x86-64. Test case attached.
OK for trunk?
Jerry
2013-04-01 Jerry DeLisle jvdeli...@gcc.gnu.org
PR libfortran/56660
* io/list_read.c (nml_read_obj): Do not reset the read error flag
inside nml_read_obj. If the read error flag is found set just exit.
Fix some whitespace on comments.
(nml_read_obj_data): Reset the read error flag before the first call
to nml_read_object.
Index: list_read.c
===
--- list_read.c (revision 197290)
+++ list_read.c (working copy)
@@ -2490,9 +2490,9 @@ nml_read_obj (st_parameter_dt *dtp, namelist_info
size_t obj_name_len;
void * pdata;
- /* This object not touched in name parsing. */
-
- if (!nl-touched)
+ /* If we have encountered a previous read error or this object has not been
+ touched in name parsing, just return. */
+ if (dtp-u.p.nml_read_error || !nl-touched)
return true;
dtp-u.p.repeat_count = 0;
@@ -2532,10 +2532,8 @@ nml_read_obj (st_parameter_dt *dtp, namelist_info
- GFC_DESCRIPTOR_LBOUND(nl,dim))
* GFC_DESCRIPTOR_STRIDE(nl,dim) * nl-size);
- /* Reset the error flag and try to read next value, if
- dtp-u.p.repeat_count=0 */
+ /* If we are finished with the repeat count, try to read next value. */
- dtp-u.p.nml_read_error = 0;
nml_carry = 0;
if (--dtp-u.p.repeat_count = 0)
{
@@ -2564,8 +2562,8 @@ nml_read_obj (st_parameter_dt *dtp, namelist_info
break;
case BT_REAL:
- /* Need to copy data back from the real location to the temp in order
- to handle nml reads into arrays. */
+ /* Need to copy data back from the real location to the temp in
+ order to handle nml reads into arrays. */
read_real (dtp, pdata, len);
memcpy (dtp-u.p.value, pdata, dlen);
break;
@@ -3022,6 +3020,7 @@ get_name:
nl = first_nl;
}
+ dtp-u.p.nml_read_error = 0;
if (!nml_read_obj (dtp, nl, 0, pprev_nl, nml_err_msg, nml_err_msg_size,
clow, chigh))
goto nml_err_ret;
! { dg-do run }
! PR56660 Fails to read NAMELIST with certain form array syntax
type ptracer
character(len = 2) :: sname
logical :: lini
end type ptracer
type(ptracer) , dimension(3) :: tracer
namelist/naml1/ tracer
tracer(:) = ptracer('XXX', .false.)
open (99, file='nml.dat', status=replace)
write(99,*) naml1
!write(99,*)tracer(2) = 'bb' , .true.
write(99,*)tracer(:) = 'aa' , .true.
write(99,*)tracer(2) = 'bb' , .true.
write(99,*) /
rewind(99)
read (99, nml=naml1)
close (99, status=delete)
if (tracer(1)%sname.ne.'aa') call abort()
if (.not.tracer(1)%lini) call abort()
if (tracer(2)%sname.ne.'bb') call abort()
if (.not.tracer(2)%lini) call abort()
if (tracer(3)%sname.ne.'XX') call abort()
if (tracer(3)%lini) call abort()
!write (*, nml=naml1)
end
Re: [patch,libfortran] PR56660 Fails to read NAMELIST with certain form array syntax
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 passed by.
The problem is resolved by moving the error flag reset outside nml_read_obj just
before the call to nml_read_obj. Also, we test the flag on entering
nml_read_obj, and if it is set, we bail out right away, a do nothing, until the
parent nml_read_obj finishes its loops.
Regression tested on x86-64. Test case attached.
OK for trunk?
OK - and thanks for the patch!
* * *
Do we want to close PR 56786? While it is a regression from 4.6, it
seems to only occur for slightly invalid namelists - unless, I missed
some fineprint. Or do we want to backport it to all/some of 4.6 / 4.7 /
4.8?
* * *
The test case below is motivated by this PR56660 and the original
PR49791. It fails with Cannot match namelist object name 'cc'. I was
wondering whether we should support that extended read (= vendor
extension) or not. Ifort and g95 do; pathf95, Crayftn, pgf95 and NAG don't.
(gfortran supports the extended read for simpler variants, e.g. PR49791,
comment 0 and comment 18.)
Tobias
type ptracer
character(len = 2) :: sname
logical :: lini
end type ptracer
type(ptracer) , dimension(3) :: tracer
namelist/naml1/ tracer
tracer(:) = ptracer('XXX', .false.)
write (*, nml=naml1)
open (99, file='nml.dat', status=replace)
write(99,*) naml1
write(99,*)tracer(:) = 'aa' , .true.
write(99,*)tracer(2) = 'bb' , .true., 'cc', .true. ! Extended
read: Two DT elements
write(99,*) /
rewind(99)
read (99, nml=naml1)
write (*, nml=naml1)
close (99, status=delete)
end
Re: Fill more delay slots in conditional returns
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 RETURN or a SIMPLE_RETURN. What does the RTL for your conditional return look like (if_then_else (cond) (pc) (return)) Where the (pc) and (return) can be reversed as well? That's what the later hunks in get_branch_condition seem to imply. It's the usual support for branches and inverted branches applied to returns, so I'm not sure what you're asking here. :-) The cleanup stuff is OK, check that in whenver you'd like. Thanks. -- Eric Botcazou
Re: [patch] cilkplus: Array notation for C patch
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 Balaji has posted has all of our changes against trunk. It is the current state of the cilkplus-merge branch. Joseph, fire away :).
Re: [var-template] Accept variable template declaration
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 that necessary? -- Gaby
Re: [var-template] Accept variable template declaration
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 template. OK but I am a little bit dense here: why is that necessary? By 'primary' I mean something that is itself a template, not just a member of a class template. Previously variables couldn't be primary templates, but I believe your proposal is to change that; in that case, we should expect to see a template header for such a template, in addition to any headers for enclosing classes. Jason
Re: [patch] cilkplus: Array notation for C patch
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 encountering tests like this
(distilled from one of the tests you added):
houston:/build/cilkplus-merge1/gcc$ cat a.c
int array[10][10];
int array2[10];
void foo()
{
array[:][:] = array2[:];
}
Currently we are issuing this error:
houston:/build/cilkplus-merge1/gcc$ ./cc1 a.c -fcilkplus -quiet
a.c: In function 'foo':
a.c:6:15: error: rank mismatch between 'array' and 'array2'
array[:][:] = array2[:];
^
Ideally, we should issue something like (notice the carets):
error: rank mismatch between 'array' and 'array2'
array[:][:] = array2[:];
^
note: original mismatching rank at:
array[:][:] = array2[:];
^
Or something similar... the note can be emitted with inform(). So you
need to save the original rank location to emit the note.
[Patch, Fortran, OOP] PR 56284: ICE with alternate return in type-bound procedure
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 should mention that we already have a warning for alternate return, but this only triggers if there is an actual RETURN statement (which is not the case for the test code in the PR). The warning I'm adding triggers on the appearance of an asterisk argument. This induces a certain redundancy, i.e. we warn about both the alternate-return argument and the alternate RETURN statement. The question is if we want to keep this, or whether on can remove the old warning for the RETURN statement (which could be done in a follow-up patch). The patch is regtested on x86_64-unknown-linux-gnu. Ok for trunk? Cheers, Janus 2013-04-01 Janus Weil ja...@gcc.gnu.org PR fortran/56284 PR fortran/40881 * decl.c (gfc_match_formal_arglist): Warn about alternate-return arguments. * interface.c (check_dummy_characteristics): Return if symbols are NULL. 2013-04-01 Janus Weil ja...@gcc.gnu.org PR fortran/56284 PR fortran/40881 * gfortran.dg/altreturn_8.f90: New. * gfortran.dg/altreturn_2.f90: Add -std=legacy. * gfortran.dg/intrinsic_actual_3.f90: Ditto. * gfortran.dg/invalid_interface_assignment.f90: Ditto. pr56284.diff Description: Binary data altreturn_8.f90 Description: Binary data
RE: [patch] cilkplus: Array notation for C patch
-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 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 encountering tests like this (distilled from
one
of the tests you added):
houston:/build/cilkplus-merge1/gcc$ cat a.c int array[10][10]; int array2[10];
void foo()
{
array[:][:] = array2[:];
}
Currently we are issuing this error:
houston:/build/cilkplus-merge1/gcc$ ./cc1 a.c -fcilkplus -quiet
a.c: In function 'foo':
a.c:6:15: error: rank mismatch between 'array' and 'array2'
array[:][:] = array2[:];
^
Ideally, we should issue something like (notice the carets):
error: rank mismatch between 'array' and 'array2'
array[:][:] = array2[:];
^
OK, I understand it a bit better now. Please let me know if I am mistaken here:
We need to do EXPR_LOCATION (array2) and then issue the error
note: original mismatching rank at:
array[:][:] = array2[:];
^
Or something similar... the note can be emitted with inform(). So you need to
save the original rank location to emit the note.
...and we take the location information in loc and print that out in inform?
Did I get it right?
Thanks,
Balaji V. Iyer.
Re: [var-template] Accept variable template declaration
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 (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 that necessary? By 'primary' I mean something that is itself a template, not just a member of a class template. Previously variables couldn't be primary templates, but I believe your proposal is to change that; in that case, we should expect to see a template header for such a template, in addition to any headers for enclosing classes. Ah, yes; got it. Thanks! -- Gaby
C++ PATCH for c++/56794 (range for and variadic template)
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, trunk.
commit ab873d428ec43d33d1e34567749104cc5a9544ad
Author: Jason Merrill ja...@redhat.com
Date: Mon Apr 1 15:45:54 2013 -0400
PR c++/56794
* parser.c (cp_parser_range_for): Don't try to do auto deduction
in a template if the type of the range is incomplete.
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index f29e80d..05c03f4 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -9615,7 +9615,10 @@ cp_parser_range_for (cp_parser *parser, tree scope, tree init, tree range_decl)
range_expr = error_mark_node;
stmt = begin_range_for_stmt (scope, init);
finish_range_for_decl (stmt, range_decl, range_expr);
- if (!type_dependent_expression_p (range_expr)
+ if (range_expr != error_mark_node
+ !type_dependent_expression_p (range_expr)
+ /* The length of an array might be dependent. */
+ COMPLETE_TYPE_P (TREE_TYPE (range_expr))
/* do_auto_deduction doesn't mess with template init-lists. */
!BRACE_ENCLOSED_INITIALIZER_P (range_expr))
do_range_for_auto_deduction (range_decl, range_expr);
diff --git a/gcc/testsuite/g++.dg/cpp0x/range-for24.C b/gcc/testsuite/g++.dg/cpp0x/range-for24.C
new file mode 100644
index 000..b4a5b18
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/range-for24.C
@@ -0,0 +1,15 @@
+// PR c++/56794
+// { dg-require-effective-target c++11 }
+
+templateint... values
+static void Colors()
+{
+static const int colors[] = { values... };
+
+for(auto c: colors) { }
+}
+
+int main()
+{
+Colors0,1,2 ();
+}
