[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.
