[Bug libstdc++/56785] std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785 --- Comment #1 from Marc Glisse 2013-03-30 09:06:44 UTC --- I assume (needs to be checked) this is related to the issue, reported elsewhere, that makes the size of std::tuple>>> grow linearly with the nesting depth.
[Bug target/50829] avx extra copy for _mm256_insertf128_pd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50829 --- Comment #13 from Marc Glisse 2013-03-30 10:13:46 UTC --- (In reply to comment #10) > Created attachment 28846 [details] > Use subreg The patch was submitted at http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00683.html and rejected, see the discussion in that thread. We need a way to completely remove the pattern.
[Bug libfortran/56786] New: [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 Bug #: 56786 Summary: [4.6/4.7/4.8/4.9 Regression] Namelist read fails with designators containing embedded spaces Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: jvdeli...@gcc.gnu.org, tiloschw...@gcc.gnu.org Blocks: 56744 Split off from PR 52512. The following program runs successfully with GCC 4.1, 4.3 and 4.5, but it fails with GCC 4.6 to GCC 4.9. It also works with Crayftn, PGI and ifort. The problem is the space in "i(3 )=". Strictly speaking, that is invalid but as it worked before, others support it as well, and as ignoring spaces in "name(...)" is nonambiguous, I believe that we should support it. (F2008, "10.11.2 Name-value subsequences", paragraph 2 has: "Each designator may be preceded and followed by one or more optional blanks but shall not contain embedded blanks.") integer :: i(3) namelist /nml/ i i = -42 open(99,status='scratch') write(99,'(a)') '&nml i(3 ) = 5 /' rewind(99) read(99,nml=nml) close(99) write(*,nml=nml) if (i(1)/=-42 .or. i(2)/=-42 .or. i(3)/=5) call abort() end
[Bug fortran/52512] Cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52512 --- Comment #7 from Tobias Burnus 2013-03-30 10:18:48 UTC --- (In reply to comment #6) > This bug fixed by Tilo's patch. > Closing. Jerry, please read the PRs carefully before you close them. The issue in mentioned in comment 4 is not fixed! I have now filled a new PR for that issue: PR56786.
[Bug fortran/56743] Namelist bug with comment and no blank
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56743 --- Comment #4 from Tobias Burnus 2013-03-30 10:47:30 UTC --- Created attachment 29752 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29752 Test case - please read comment in the file or comment 4 The test case is successful with ifort 13.1, it fails (iostat/=0, run time failure) with Crayftn and PGI already for "i=1!". According to the Fortran standard, the example - as the example in comment 0 - is invalid. From Fortran 2008, "10.11.3.6 Namelist comments": "Except within a character literal constant, a "!" character after a value separator or in the first nonblank position of a namelist input record initiates a comment." Note the "after a value separator". In "i=1!" there is no value separator after the value "1". For my character example "c1 = a": Also that example is invalid according to the Fortran standard, which states in "10.11.3.3 Namelist input values": "When the next effective item is of type character, the input form consists of a delimited sequence of zero or more rep-chars [...]" Thus, either " or ' is required as delimiter - but the example doesn't use neither. EXPECTED RESULTS: (a) "i=1!" is either accepted as vendor extension as "i=1 !...", matching Intel's result. Or it is rejected with a compile-time error as Crayftn and PGI do it. Currently, integers and reals (except for INF/NAN) give not error but the result is not modified (BUG!). For logical, complex and delimited character strings, the value is read (as vendor extension), and for INF and NAN a "cannot match namelist object" error is shown - which is acceptable according to the standard an matches PGI/Crayftn. (b) For nondelimited character strings: Currently, it gives the error "Cannot match namelist object", which is fine according to the standard. One could still consider to support reading it as vendor extension - as Intel does. (Simply read from the first nonspace character to the first value separator.)
[Bug other/56721] libffi.info installed in share/info collides with that from libffi itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56721 Matthias Klose changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||doko at gcc dot gnu.org Version|4.8.0 |4.8.1 Resolution||FIXED --- Comment #3 from Matthias Klose 2013-03-30 11:27:56 UTC --- now fixed on trunk and the 4.8 branch.
[Bug target/48326] Target attribute leaks from function pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48326 --- Comment #3 from Mikael Pettersson 2013-03-30 11:59:19 UTC --- I can reproduce the initial bug with gcc 4.4.7, 4.5.3, 4.6.3, and 4.7.0, but not with 4.5.4, 4.6-20130322, 4.7.1, or 4.7.2.
[Bug debug/56783] g++ does not supply signatures for gdb on g++ 4.7 versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #8 from Jonathan Wakely 2013-03-30 12:10:41 UTC --- (In reply to comment #6) > First, my apology for not giving the gdp version. I assume you meant this: > GNU gdb 6.3.50-20050815 (Apple version gdb-1515) (Sat Jan 15 08:33:48 UTC > 2011) Donate it to a museum and try a GDB version that was released this side of the last ice age. GCC 4.5 and later require at least GDB 7.0: http://gcc.gnu.org/gcc-4.5/changes.html This is not GCC bug.
[Bug target/48326] Target attribute leaks from function pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48326 --- Comment #4 from Mikael Pettersson 2013-03-30 12:31:38 UTC --- The initial bug was fixed by r187169 on 4.7 branch, I'd say it's clearly a dup of PR53228.
[Bug c/52952] Wformat location info is bad (wrong column number)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #15 from Manuel López-Ibáñez 2013-03-30
12:32:08 UTC ---
(In reply to comment #13)
> I guess the C/C++ FEs could for non-trivial string literals put into a hash
> table mapping from locus_t (of ADDR_EXPR around STRING_CST) to the first cpp
> token for that string, then the diagnostic code could go from there.
> Trivial string literal above would be a string literal that doesn't have any
> prefixes (L/u/u8/U and variants with R), isn't contatenated from several parts
> 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
> need that. For "trivial" string literals you'd just shift the locus by the
> offset, for non-trivial look up the tokens and process them again, looking at
> where the corresponding byte would appear to come from.
Jakub, I am trying to implement this idea, but I am not sure I got the
hash_table right. It looks overly complicated to me. Could you take a look?
[Bug c/52952] Wformat location info is bad (wrong column number)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952 --- Comment #16 from Manuel López-Ibáñez 2013-03-30 12:32:57 UTC --- Created attachment 29753 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29753 loc_token_hash
[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 changed: What|Removed |Added CC||joseph at codesourcery dot ||com --- Comment #17 from Manuel López-Ibáñez 2013-03-30 12:40:24 UTC --- BTW, I have a patch based on Steven's one that is almost working and for simple strings handles a location+offset. However, there are several issues: * Cases like: 1: const str[] = "something %d"; 2: printf(str); will report a location at 2 plus offset of %d, not nice. * I didn't transform the most obscure format warnings. Some of them have no easy location at hand and others I simply don't know what we want to point at. * It would be extremely nice to update the testsuite to check the locations are correct. This is unfortunately a lot of boring work, so if I cannot get help to do this, I hope it is not a pre-condition for approval.
[Bug c/52952] Wformat location info is bad (wrong column number)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952 --- Comment #18 from stevenb.gcc at gmail dot com 2013-03-30 12:54:12 UTC --- > * It would be extremely nice to update the testsuite to check the locations > are > correct. This is unfortunately a lot of boring work, so if I cannot get help > to > do this, I hope it is not a pre-condition for approval. You mean for existing test cases? I will help with that, just say what/where/when ;-)
[Bug c/52952] Wformat location info is bad (wrong column number)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952 --- Comment #19 from Manuel López-Ibáñez 2013-03-30 13:26:19 UTC --- Unfortunately, there are some stuff like this: BLK size unit size align 8 symtab 0 alias set -1 canonical type 0x77094540 domain pointer_to_this > unsigned DI size unit size align 64 symtab 0 alias set -1 canonical type 0x77094690> readonly constant arg 0 readonly constant static "%s:%d: %s: Assertion '%s' failed.\012\000">> so we cannot assert that the format_expr has no unknown location.
[Bug libfortran/49791] [4.6/4.7/4.8/4.9 Regression] Formatted namelist reads fails with: Cannot match namelist object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #26 from Tobias Burnus 2013-03-30 14:45:45 UTC --- (In reply to comment #25) > Lets close this one and carry forward on PR56660. PR56660 is about comment 19. The other issue, comment 18, has been fixed meanwhile. (By one of the recent 4.9 patches; GCC 4.8.0 fails.)
[Bug fortran/56660] Fails to read NAMELIST with certain form array syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56660 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus 2013-03-30 14:49:32 UTC --- The example in comment 0 is based on PR49791 comment 19, see also PR49791 comment 24 with its related test case attachment 29751. When closing, check that all those variants are fixed as well.
[Bug debug/56783] g++ does not supply signatures for gdb on g++ 4.7 versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783 --- Comment #9 from Dick Guertin 2013-03-30 14:52:33 UTC --- (In reply to comment #8) > (In reply to comment #6) > > First, my apology for not giving the gdp version. I assume you meant this: > > GNU gdb 6.3.50-20050815 (Apple version gdb-1515) (Sat Jan 15 08:33:48 UTC > > 2011) > > Donate it to a museum and try a GDB version that was released this side of the > last ice age. GCC 4.5 and later require at least GDB 7.0: > http://gcc.gnu.org/gcc-4.5/changes.html > > This is not GCC bug. Johnathan, this may not be a GCC bug, but it isn't a GDB bug either. I went back to g++ 4.2 that came with the Xcode, which is where I started. Of course, the problem persists. The "problem" is in the linked modules. They don't contain the paths back to the "source" modules. "g++" compiles source into objects; "ld" links objects into a link module, but knows about the sources. In Mac OS X 10.4.11, the linker places path-references back to sources. In 10.5 and 10.6, it references back to objects. When "gdb" reads the linked module, it needs the sources to construct the "signatures" for the symbol-table. Paths to objects are worthless in this regard. The fact that "gdb" works properly with linked modules brought across from OS 10.4.11 (with identical sources on identical paths), shows that the path-references to sources is the key. The latest "ld" is failing. Of course, another problem would be the lack of sources when trying to "gdb" the linked module. I achieved that simply by renaming one of the directories leading to the sources, and even my 10.4.11 linked module then failed to debug.
[Bug c/56787] New: 4.8.0 Vectorization Regression Compared to 4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56787 Bug #: 56787 Summary: 4.8.0 Vectorization Regression Compared to 4.7.2 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: fred...@witherden.org Created attachment 29754 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29754 Test case When compiling the attached file with GCC 4.8.0 on an AVX capable system the main loop isn't vectorized. This is a regression compared with 4.7.2 on the same system (where the loop is fully vectorized). I apologize for the length of the test case -- smaller examples do not reproduce the behaviour in question. Output of -save-temps: gcc-mp-4.8 -v -save-temps -Ofast -march=native -std=c99 -S test.c Using built-in specs. COLLECT_GCC=gcc-mp-4.8 Target: x86_64-apple-darwin12 Configured with: ../gcc-4.8-20130321/configure --prefix=/opt/local --build=x86_64-apple-darwin12 --enable-languages=c,c++,objc,obj-c++,fortran,java --libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.8 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.8 --with-gxx-include-dir=/opt/local/include/gcc48/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local --with-cloog=/opt/local --enable-cloog-backend=isl --disable-cloog-version-check --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts gcc48 4.8-20130321_0' Thread model: posix gcc version 4.8.0 20130321 (prerelease) (MacPorts gcc48 4.8-20130321_0) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.8.3' '-v' '-save-temps' '-Ofast' '-march=native' '-std=c99' '-S' /opt/local/libexec/gcc/x86_64-apple-darwin12/4.8.0/cc1 -E -quiet -v -D__DYNAMIC__ test.c -march=corei7-avx -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=3072 -mtune=corei7-avx -fPIC -mmacosx-version-min=10.8.3 -std=c99 -Ofast -fpch-preprocess -o test.i ignoring nonexistent directory "/opt/local/lib/gcc48/gcc/x86_64-apple-darwin12/4.8.0/../../../../../x86_64-apple-darwin12/include" #include "..." search starts here: #include <...> search starts here: /opt/local/lib/gcc48/gcc/x86_64-apple-darwin12/4.8.0/include /opt/local/include /opt/local/lib/gcc48/gcc/x86_64-apple-darwin12/4.8.0/include-fixed /usr/include /System/Library/Frameworks /Library/Frameworks End of search list. COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.8.3' '-v' '-save-temps' '-Ofast' '-march=native' '-std=c99' '-S' /opt/local/libexec/gcc/x86_64-apple-darwin12/4.8.0/cc1 -fpreprocessed test.i -march=corei7-avx -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=3072 -mtune=corei7-avx -fPIC -quiet -dumpbase test.c -mmacosx-version-min=10.8.3 -auxbase test -Ofast -std=c99 -version -o test.s GNU C (MacPorts gcc48 4.8-20130321_0) version 4.8.0 20130321 (prerelease) (x86_64-apple-darwin12) compiled by GNU C version 4.8.0 20130321 (prerelease), GMP version 5.0.5, MPFR version 3.1.1-p2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (MacPorts gcc48 4.8-20130321_0) version 4.8.0 20130321 (prerelease) (x86_64-apple-darwin12) compiled by GNU C version 4.8.0 20130321 (prerelease), GMP version 5.0.5, MPFR version 3.1.1-p2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 6291d2010395c7dee8043d72914d31cb COMPILER_PATH=/opt/local/libexec/gcc/x86_64-apple-darwin12/4.8.0/:/opt/local/libexec/gcc/x86_64-apple-darwin12/4.8.0/:/opt/local/libexec/gcc/x86_64-apple-darwin12/:/opt/local/lib/gcc48/gcc/x86_64-apple-darwin12/4.8.0/:/opt/local/lib/gcc48/gcc/x86_64-apple-darwin12/ LIBRARY_PATH=/opt/local/lib/gcc48/gcc/x86_64-apple-darwin12/4.8.0/:/opt/local/lib/gcc48/gcc/x86_64-apple-darwin12/4.8.0/../../../:/usr/lib/ COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.8.3' '-v' '-save
[Bug fortran/56735] [4.6/4.7/4.8/4.9 Regression] Namelist Read Error with question marks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56735 --- Comment #8 from Tobias Burnus 2013-03-30 15:00:11 UTC --- The issue has been fixed on the 4.9 development branch - and it is scheduled for backporting to the 4.6, 4.7 and 4.8 release branches. See http://gcc.gnu.org/wiki/GFortranBinaries for regular nonofficial builds and how to build GCC yourself. (In reply to comment #0) > -test.nam > ? > > $temp The "?" causes the problem. The "?" is rather pointless if the data is read from a file - and for files read from stdin, it only outputs the available items in the name list. Thus, a workaround is to either remove the "?" line, to comment it out, or to change the "?" into "=?". I don't know whether the workaround helps you - or updating to a fixed GCC version. But in any case, I want to say sorry for the regression and thanks for the bug report!
[Bug c/52952] Wformat location info is bad (wrong column number)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952 --- Comment #20 from Manuel López-Ibáñez 2013-03-30 15:02:11 UTC --- (In reply to comment #18) > > * It would be extremely nice to update the testsuite to check the locations > > are > > correct. This is unfortunately a lot of boring work, so if I cannot get > > help to > > do this, I hope it is not a pre-condition for approval. > > You mean for existing test cases? I will help with that, just say > what/where/when ;-) I personally think that it would be better to spend our extremely limited human resources on adding more explicit locations and offsets to the various warnings and checking that they are correct. This can be done by running with my current patch the following: make check-gcc RUNTESTFLAGS='format.exp=*.c --target_board="unix/-fdiagnostics-show-caret"' and checking if the output is what one would expect. If later we regress, then we could update/add testcases.
[Bug c/52952] Wformat location info is bad (wrong column number)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952 --- Comment #21 from Manuel López-Ibáñez 2013-03-30 15:03:14 UTC --- Created attachment 29755 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29755 add locations and offsets to format warnings My current patch, untested except for a few testcases.
[Bug fortran/56735] [4.6/4.7/4.8/4.9 Regression] Namelist Read Error with question marks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56735 --- Comment #9 from Adam Williams 2013-03-30 18:42:44 UTC --- This is great. I look forward to testing when I get a chance to build from the latest dev branch. I understand what you mean with the "?", however they are being used in a completely non-standard way in the legacy code in question. They are actually being used as a marker in some formatted text which is kept at the top of a namelist file and read in separately. I will see if we can alter this, but unfortunately it is not my decision and backwards compatibility will need to be considered. Cheers for all your help/work
[Bug target/56788] New: _mm_frcz_sd and _mm_frcz_ss ignore their second argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56788
Bug #: 56788
Summary: _mm_frcz_sd and _mm_frcz_ss ignore their second
argument
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org
Target: x86_64-linux-gnu
#include
__m128d f(__m128d x, __m128d y){
return _mm_frcz_sd(x,y);
}
is compiled to:
vfrczsd%xmm0, %xmm0
ret
Notice the lack of any reference to xmm1...
In my opinion, __builtin_ia32_vfrczsd should take a single argument, and the
intrinsic should call first this builtin and then __builtin_ia32_movsd.
[Bug target/56788] _mm_frcz_sd and _mm_frcz_ss ignore their second argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56788 --- Comment #1 from Marc Glisse 2013-03-30 20:42:51 UTC --- _mm_frcz_ss is inconsistent between compilers. Microsoft gives it 2 arguments and movss-like semantics, whereas clang gives it a single argument. AMD doesn't document intrinsics, and I can't find any relevant Intel doc.
[Bug c++/51440] Improve message and add an option for warning for an unnamed struct member: TYPE has a field FIELD whose type uses the anonymous namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51440 --- Comment #5 from Martin Richtarsky 2013-03-30 22:06:48 UTC --- Hi Manuel, thanks for the pointers how to add the optional warning. I will try to submit a patch, however first I would like to understand what is going on exactly: - the volatile qualifier (could also be const) leads to internal linkage - C++ has a default namespace for each translation unit where any code will be located that has no explicit namespace, and the warning here says that this structure will be local to this namespace for each translation unit that includes it the header Is this correct? Would there be any kind of workaround to change this without removing the volatile keyword? I tried these: - wrapping the include in extern "C": doesn't work - wrapping the include in an explicit namespace statement: works Best regards, Martin
[Bug fortran/56789] New: Wrong code with contiguous dummy argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789 Bug #: 56789 Summary: Wrong code with contiguous dummy argument Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org This is from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137#c15 ig25@linux-fd1f:~/Krempel/Contig> cat foo.f90 module zero implicit none contains subroutine foo(a) real, contiguous :: a(:,:) a(:,:) = 0 end subroutine foo end module zero program main use zero implicit none real, dimension(5,5) :: a a = 1. call foo(a(1:5:2,1:5:2)) ! write (*,'(5F12.5)') a end program main ig25@linux-fd1f:~/Krempel/Contig> gfortran foo.f90 ig25@linux-fd1f:~/Krempel/Contig> ./a.out *** glibc detected *** ./a.out: free(): invalid next size (fast): 0x00629f90 *** a.out: malloc.c:2451: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed. Program received signal SIGABRT: Process abort signal. Backtrace for this error: [...] ig25@linux-fd1f:~/Krempel/Contig> valgrind ./a.out ==19631== Memcheck, a memory error detector ==19631== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==19631== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==19631== Command: ./a.out ==19631== ==19631== Invalid write of size 4 ==19631==at 0x4007F7: __zero_MOD_foo (in /home/ig25/Krempel/Contig/a.out) ==19631==by 0x4008E8: MAIN__ (in /home/ig25/Krempel/Contig/a.out) ==19631==by 0x40095A: main (in /home/ig25/Krempel/Contig/a.out) ==19631== Address 0x5c38428 is 4 bytes after a block of size 36 alloc'd ==19631==at 0x4C2ABED: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==19631==by 0x4E4C714: _gfortrani_xmalloc (memory.c:38) ==19631==by 0x4EE9B23: _gfortrani_internal_pack_r4 (in_pack_r4.c:79) ==19631==by 0x4008CF: MAIN__ (in /home/ig25/Krempel/Contig/a.out) ==19631==by 0x40095A: main (in /home/ig25/Krempel/Contig/a.out) ==19631== ==19631== ==19631== HEAP SUMMARY: ==19631== in use at exit: 0 bytes in 0 blocks ==19631== total heap usage: 22 allocs, 22 frees, 11,858 bytes allocated ==19631== ==19631== All heap blocks were freed -- no leaks are possible ==19631== ==19631== For counts of detected and suppressed errors, rerun with: -v ==19631== ERROR SUMMARY: 6 errors from 1 contexts (suppressed: 2 from 2)
[Bug fortran/56789] Wrong code with contiguous dummy argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789 Thomas Koenig changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Thomas Koenig 2013-03-30 22:35:51 UTC --- The problem is that we pack the data, but do not adjust the descriptor accordingly. The dump looks like this: parm.10.dtype = 282; parm.10.dim[0].lbound = 1; parm.10.dim[0].ubound = 3; parm.10.dim[0].stride = 2; parm.10.dim[1].lbound = 1; parm.10.dim[1].ubound = 3; parm.10.dim[1].stride = 10; parm.10.data = (void *) &a[0]; parm.10.offset = 0; origptr.11 = parm.10.data; D.1929 = _gfortran_internal_pack (&parm.10); parm.10.data = D.1929; foo (&parm.10); and it should look like this: parm.12.dim[0].lbound = 1; parm.12.dim[0].ubound = 3; parm.12.dim[0].stride = 1; parm.12.dim[1].lbound = 1; parm.12.dim[1].ubound = 3; parm.12.dim[1].stride = 3; [...]
[Bug tree-optimization/56790] New: VEC_COND_EXPR not constant folded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56790
Bug #: 56790
Summary: VEC_COND_EXPR not constant folded
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org
Target: x86_64-linux-gnu
#include
__m128d f(){
__m128d a={5,7};
__m128d b={11,13};
__m128i m={-1,0};
return m?a:b;
}
With -msse3 or less, this is lowered to scalar operations and thus to a
constant. However, with -msse4 or higher, nothing folds it to a constant,
either at tree level or rtl level, and we end up with:
pxor%xmm0, %xmm0
pcmpgtq.LC0(%rip), %xmm0
movapd.LC2(%rip), %xmm1
blendvpd%xmm0, .LC1(%rip), %xmm1
movapd%xmm1, %xmm0
The most natural seems to be to add something to fold-const.c, which currently
only handles the case where the first argument is all 1s or all 0s. It would be
good if the optimization worked when the second and third arguments can be
either VECTOR_CST or CONSTRUCTOR, similarly to VEC_PERM_EXPR.
[Bug bootstrap/56714] [4.9 regression] Bootstrap failure libitm/local_atomic:1580:3: error: always_inline function might not be inlinable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56714 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Jan Hubicka 2013-03-30 23:12:56 UTC --- Well, the error message means that the function is not inline (either !DECLARED_INLINE or UNINLINABLE) and has always_inline flag. Can you attach the preprocessed source file? Honza
[Bug bootstrap/56714] [4.9 regression] Bootstrap failure libitm/local_atomic:1580:3: error: always_inline function might not be inlinable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56714 --- Comment #2 from Gerald Pfeifer 2013-03-30 23:35:26 UTC --- Created attachment 29756 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29756 Pre-processed source aatree.ii All those always_inline attributes seem to come from libitm/local_atomic.
[Bug middle-end/56791] New: Segmentation fault in stage2 gengenrtl -- Incorrect instruction sequence generated by reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56791
Bug #: 56791
Summary: Segmentation fault in stage2 gengenrtl -- Incorrect
instruction sequence generated by reload
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
Host: hppa1.1-hp-hp10.20
Target: hppa1.1-hp-hp10.20
Build: hppa1.1-hp-hp10.20
Created attachment 29757
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29757
Preprocessed source
/xxx/gnu/gcc/objdir/./prev-gcc/xg++ -B/xxx/gnu/gcc/objdir/./prev-gcc/
-B/opt/gnu/gcc/gcc-4.8/hppa1.1-hp-hpux10.20/bin/ -nostdinc++
-B/xxx/gnu/gcc/objdir/prev-hppa1.1-hp-hpux10.20/libstdc++-v3/src/.libs
-B/xxx/gnu/gcc/objdir/prev-hppa1.1-hp-hpux10.20/libstdc++-v3/libsupc++/.libs
-I/xxx/gnu/gcc/objdir/prev-hppa1.1-hp-hpux10.20/libstdc++-v3/include/hppa1.1-hp-hpux10.20
-I/xxx/gnu/gcc/objdir/prev-hppa1.1-hp-hpux10.20/libstdc++-v3/include
-I/xxx/gnu/gcc/gcc/libstdc++-v3/libsupc++
-L/xxx/gnu/gcc/objdir/prev-hppa1.1-hp-hpux10.20/libstdc++-v3/src/.libs
-L/xxx/gnu/gcc/objdir/prev-hppa1.1-hp-hpux10.20/libstdc++-v3/libsupc++/.libs
-g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-DHAVE_CONFIG_H -DGENERATO
R_FILE -static-libstdc++ -static-libgcc -o build/gengenrtl \
build/gengenrtl.o build/errors.o .././libiberty/libiberty.a
build/gengenrtl > tmp-genrtl.h
/bin/sh: 9799 Memory fault(coredump)
make[3]: *** [s-genrtl-h] Error 139
In the generated assembly code, the fault occurs in the ldw instruction
using register %r19.
.CALL ARGW0=GR
bl puts,%r2
ldo RR'L$C0034(%r26),%r26
L$BE0063:
L$BE0067:
.stabn 68,0,270,L$M0084-L$FBB0002
L$M0084:
ldw 0(%r19),%r20
ldws,ma 4(%r20),%r4
%r19 is clobbered by the preceding call to puts. The problem occurs
in reload. Prior to reload, we have the following for insn 448:
(insn 448 447 450 57 (set (reg/v/f:SI 242 [ format ])
(mem/f:SI (post_inc:SI (reg/f:SI 243 [ ivtmp.101 ])) [3 MEM[base: _104,
offset: 0B]+0 S4 A32])) ../../gcc/gcc/gengenrtl.c:270 40 {*pa.md:2211}
(expr_list:REG_INC (reg/f:SI 243 [ ivtmp.101 ])
(nil)))
After reload, we have:
(call_insn 447 446 1092 57 (parallel [(set (reg:SI 28 %r28)
(call (mem:SI (symbol_ref/v:SI ("@puts") [flags 0x41]
) [0 __builtin_puts S4 A32])
(const_int 16 [0x10])))
(clobber (reg:SI 1 %r1))
(clobber (reg:SI 2 %r2))
(use (const_int 0 [0]))
]) ../../gcc/gcc/gengenrtl.c:247 203 {call_val_symref}
(nil)
(expr_list:REG_CC_SETTER (use (reg:SI 26 %r26))
(nil)))
(insn 1092 447 1091 57 (set (reg:SI 20 %r20)
(mem/c:SI (reg:SI 19 %r19) [7 %sfp+8 S4 A32]))
../../gcc/gcc/gengenrtl.c
:270 40 {*pa.md:2211}
(nil))
(insn 1091 1092 448 57 (set (reg:SI 19 %r19)
(plus:SI (reg/f:SI 30 %r30)
(const_int -120 [0xff88]))) ../../gcc/gcc/gengenrtl.c:270 112
{a
ddsi3}
(nil))
(insn 448 1091 1093 57 (set (reg/v/f:SI 4 %r4 [orig:242 format ] [242])
(mem/f:SI (post_inc:SI (reg:SI 20 %r20)) [3 MEM[base: _104, offset:
0B]+0 S4 A32])) ../../gcc/gcc/gengenrtl.c:270 40 {*pa.md:2211}
(expr_list:REG_INC (reg:SI 20 %r20)
(nil)))
Insns 1091 and 1092 are interchanged.
I'm not sure but there appears to be special handling for increment
instructions here:
if (old != 0
/* AUTO_INC reloads need to be handled even if inherited. We got an
AUTO_INC reload if reload_out is set but reload_out_reg isn't. */
&& (! reload_inherited[j] || (rl->out && ! rl->out_reg))
&& ! rtx_equal_p (reg_rtx, old)
&& reg_rtx != 0)
emit_input_reload_insns (chain, rld + j, old, j);
emit_input_reload_insns is called from the above after insn 1091 is emitted.
Can reproduce on i686-apple-darwin9.
Probably, this affects other hppa targets.
Compilation command:
-fpreprocessed gengenrtl.ii -quiet -dumpbase gengenrtl.c -mschedule=7100LC
-auxbase-strip build/gengenrtl.o -g -O2 -Wextra -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wsuggest-attribute=format -Wpedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -version
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -o gengenrtl.s
