GCC version bikeshedding
Hi! So, what versioning scheme have we actually agreed on, before I change it in wwwdocs? Is that 5.0.0 in ~ April 2015, 5.0.1 in ~ June-July 2015 and 5.1.0 in ~ April 2016, or 5.0 in ~ April 2015, 5.1 in ~ June-July 2015 and 6.0 in ~ April 2016? The only thing I understood was that we don't want 4.10, but for the rest various people expressed different preferences and then it was presented as agreement on 5.0, which applies to both of the above. It is not a big deal either way of course. Jakub
Re: GCC version bikeshedding
On July 20, 2014 5:55:06 PM GMT+01:00, Jakub Jelinek ja...@redhat.com wrote: Hi! So, what versioning scheme have we actually agreed on, before I change it in wwwdocs? Is that 5.0.0 in ~ April 2015, 5.0.1 in ~ June-July 2015 and 5.1.0 in ~ April 2016, or 5.0 in ~ April 2015, 5.1 in ~ June-July 2015 and 6.0 in ~ April 2016? The only thing I understood was that we don't want 4.10, but for the rest various people expressed different preferences and then it was presented as agreement on 5.0, which applies to both of the above. It is not a big deal either way of course. I understood we agreed on 5.0 and further 5.1, 5.2 releases from the branch and 6.0 a year later. With unspecified uses for the patch level number (so leave it at zero). Richard. Jakub
Re: GCC version bikeshedding
On Sun, Jul 20, 2014 at 05:59:08PM +0100, Richard Biener wrote: So, what versioning scheme have we actually agreed on, before I change it in wwwdocs? Is that 5.0.0 in ~ April 2015, 5.0.1 in ~ June-July 2015 and 5.1.0 in ~ April 2016, or 5.0 in ~ April 2015, 5.1 in ~ June-July 2015 and 6.0 in ~ April 2016? The only thing I understood was that we don't want 4.10, but for the rest various people expressed different preferences and then it was presented as agreement on 5.0, which applies to both of the above. It is not a big deal either way of course. I understood we agreed on 5.0 and further 5.1, 5.2 releases from the branch and 6.0 a year later. With unspecified uses for the patch level number (so leave it at zero). Ian/Jason, is that your understanding too? In any case, we should mention it on gcc.gnu.org/index.html, in develop.html and perhaps a few other spots. Jakub
Re: GCC version bikeshedding
On 20/07/14 17:59, Richard Biener wrote: On July 20, 2014 5:55:06 PM GMT+01:00, Jakub Jelinek ja...@redhat.com wrote: Hi! So, what versioning scheme have we actually agreed on, before I change it in wwwdocs? Is that 5.0.0 in ~ April 2015, 5.0.1 in ~ June-July 2015 and 5.1.0 in ~ April 2016, or 5.0 in ~ April 2015, 5.1 in ~ June-July 2015 and 6.0 in ~ April 2016? The only thing I understood was that we don't want 4.10, but for the rest various people expressed different preferences and then it was presented as agreement on 5.0, which applies to both of the above. It is not a big deal either way of course. I understood we agreed on 5.0 and further 5.1, 5.2 releases from the branch and 6.0 a year later. With unspecified uses for the patch level number (so leave it at zero). That's what I understood as well. Someone mentioned to leave the patch level number to the distros to use which sounded like a good idea. Paulo Matos Richard. Jakub
Re: GCC version bikeshedding
On Jul 20, 2014, at 5:55 PM, Jakub Jelinek ja...@redhat.com wrote: So, what versioning scheme have we actually agreed on, before I change it in wwwdocs? Is that 5.0.0 in ~ April 2015, 5.0.1 in ~ June-July 2015 and 5.1.0 in ~ April 2016, or 5.0 in ~ April 2015, 5.1 in ~ June-July 2015 and 6.0 in ~ April 2016? The only thing I understood was that we don't want 4.10, but for the rest various people expressed different preferences and then it was presented as agreement on 5.0, which applies to both of the above. Can we use the switch to 5.0, a supposedly stable C++11 ABI etc, also as an excuse to finally configure for --with-sse2 by default for 32-bit x86? Maybe then we can finally retire PR 323 and its dozens of duplicates... -Geert
Re: GCC version bikeshedding
Paulo Matos pa...@matos-sorge.com writes: That's what I understood as well. Someone mentioned to leave the patch level number to the distros to use which sounded like a good idea. Sounds like a bad idea, as then there would be non unique gcc versions. redhat gcc 5.0.2 potentially being completely different from suse gcc 5.0.2 -Andi
gcc-4.10-20140720 is now available
Snapshot gcc-4.10-20140720 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.10-20140720/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.10 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 212879 You'll find: gcc-4.10-20140720.tar.bz2Complete GCC MD5=def7351bb0877c031e6ee278aff72381 SHA1=784eaa7eaa9a90ac76000cd0e309feaed186a64f Diffs from 4.10-20140713 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.10 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[Bug fortran/53653] [IR Tracking] Disallow abstract/unlimited-polymorphic types in array constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53653 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-20 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Compiling the code in comment 0 still gives an ICE with gfortran 4.10.0 r212833: pr53653.f90: In function 'MAIN__': pr53653.f90:28:0: internal compiler error: in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:5668 allocate(y(1), source=[x]) ^ The location of the ICE is the same as for pr51864.
[Bug go/60874] FAIL: go.test/test/recover.go execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- Patch that extends libgo to use libffi closures is at [1]. [1] https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01355.html
[Bug fortran/51864] [OOP] ALLOCATE with polymorphic array constructor as SOURCE=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51864 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-20 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Compiling the code in comment 0 still gives an ICE with gfortran 4.10.0 r212833 (the same ICE as for pr53653): pr51864.f90: In function 'MAIN__': pr51864.f90:12:0: internal compiler error: in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:5668 allocate(c(8), source=[ a, b ]) ^ I also get the same ICE with the following code call pr53876 end subroutine pr53876 IMPLICIT NONE TYPE :: individual integer :: icomp ! Add an extra component to test offset REAL, DIMENSION(:), ALLOCATABLE :: genes END TYPE CLASS(individual), DIMENSION(:), ALLOCATABLE :: indv, indv1 allocate (indv(2), source = [individual(1, [99,999]), individual(2, [999,])]) allocate (indv1(2), source = [indv]) END If I understand correctly comment 1, this code should be valid. Replacing '[indv]' with '[indv(1),indv(2)]' does not fix the ICE, but replacing it with 'imdv' does.
[Bug fortran/51652] Allocate with type-spec and source-expr: check whether length type-parameter is the same is lacking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51652 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-20 Ever confirmed|0 |1 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- Fixed? Mostly for 4.8.3, 4.9.0, and trunk (4.10.0). The test in comment 0 does not compile with 4.8 (Deferred-length character component 'c' at (1) is not yet supported) and, when compiled with 4.9 or 4.10, executing the code gives 'no': 'kw(1)%c(1)' is empty.
[Bug fortran/53357] Add -fcheck=bounds for character type-spec in ALLOCATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53357 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-07-20 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Compiling the first test in comment 0 gives an error with 4.7 up to trunk (4.10) Error: Allocating str at (1) with type-spec requires the same character-length parameter as in the declaration even if i=3 or with the following code integer :: i i = 3 call sub(i) end subroutine sub(i) character(len=i), allocatable :: str allocate (character(len=3) :: str) end This does not seem correct (unless I am missing something).
[Bug go/60874] FAIL: go.test/test/recover.go execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-07-20 Ever confirmed|0 |1 --- Comment #2 from Ian Lance Taylor ian at airs dot com --- The patch is committed so this bug may be fixed. I haven't tested it on Alpha, though.
[Bug tree-optimization/61829] SEGV in fold_binary_loc for gcc.dg/graphite/isl-codegen-loop-dumping.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61829 romangareev at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from romangareev at gcc dot gnu.org --- This was fixed in r212863.
[Bug c/61852] Incorrect column number for -Wimplicit-function-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61852 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Sun Jul 20 10:43:26 2014 New Revision: 212865 URL: https://gcc.gnu.org/viewcvs?rev=212865root=gccview=rev Log: PR c/61852 * c-decl.c (implicit_decl_warning): Add location_t parameter. Use it. (implicitly_declare): Pass location to implicit_decl_warning. * gcc.dg/pr61852.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr61852.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/testsuite/ChangeLog
[Bug c/61852] Incorrect column number for -Wimplicit-function-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61852 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #25 from Jürgen Reuter juergen.reuter at desy dot de --- Created attachment 33158 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33158action=edit Reduced test case, 140 lines
[Bug c/61855] New: _MM_MANTISSA_NORM_ENUM in avx512intrin.h disabled when optimization off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61855 Bug ID: 61855 Summary: _MM_MANTISSA_NORM_ENUM in avx512intrin.h disabled when optimization off Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: agner at agner dot org Created attachment 33159 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33159action=edit test code to replicate bug Definitions _MM_MANTISSA_NORM_ENUM and _MM_MANTISSA_SIGN_ENUM in avx512intrin.h are disabled when optimization is off. To replicate error, compile attached file with gcc -c -mavx512f -O0 bug2.c Workaround: gcc -c -mavx512f -O1 bug2.c
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #26 from Jürgen Reuter juergen.reuter at desy dot de --- I cooked down the problem to a 140 line test case with which you should be able to find the culprit. Just do: gfortran iso_varying_string.o whizard_test.f90 and run ./a.out It doesn't need any more input files, and only depends on the standard iso_varying_string.f90.
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #27 from Jürgen Reuter juergen.reuter at desy dot de --- Dominique, I tested your proposed fix from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831#c23 But it doesn't work, the problem still occurs.
[Bug target/61154] [4.10 Regression][ARM] wide-int merge introduced regressions in vshuf tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61154 --- Comment #11 from yroux at gcc dot gnu.org --- Author: yroux Date: Sun Jul 20 12:04:22 2014 New Revision: 212866 URL: https://gcc.gnu.org/viewcvs?rev=212866root=gccview=rev Log: 2014-07-20 Yvan Roux yvan.r...@linaro.org Revert: 2014-07-16 Yvan Roux yvan.r...@linaro.org Backport from trunk r211129. 2014-06-02 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR target/61154 * config/arm/arm.h (TARGET_SUPPORTS_WIDE_INT): Define. * config/arm/arm.md (mov64 splitter): Replace const_double_operand with immediate_operand. Modified: branches/linaro/gcc-4_9-branch/gcc/ChangeLog.linaro branches/linaro/gcc-4_9-branch/gcc/config/arm/arm.h branches/linaro/gcc-4_9-branch/gcc/config/arm/arm.md
[Bug c++/61856] New: Ternary operator in an NSDMI causes double evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61856
Bug ID: 61856
Summary: Ternary operator in an NSDMI causes double evaluation
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
First test:
#include iostream
#ifdef OK
struct ostream { } cout;
bool operator(ostream, const char* s)
{ __builtin_printf(%s, s); return true; }
#else
using std::cout;
#endif
struct X { int a = (couthmm\n) ? 1 : 2;};
int main()
{
X x;
}
With -DOK, this prints hmm once, otherwise it prints hmm twice. This
suggested
that perhaps the problem is specific to iostream, but wrapping the NSDMI into
a lambda fixes the double evaluation:
#include iostream
#ifdef OK
struct ostream { } cout;
bool operator(ostream, const char* s)
{ __builtin_printf(%s, s); return true; }
#else
using std::cout;
#endif
struct X { int a = ([]{return bool(couthmm\n);}()) ? 1 : 2;};
int main()
{
X x;
}
Simpler cases like just incrementing a global variable in the ternary
operator seem to work fine:
#include iostream
int global_x = 0;
struct X { int a = (global_x++) ? 1 : 2;};
int main()
{
X x;
std::cout global_x std::endl;
}
Perhaps this is some weird gimplification bug.
[Bug c++/61856] Ternary operator in an NSDMI causes double evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61856 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-20 Ever confirmed|0 |1
[Bug c++/61857] New: An init-capturing lambda is parsed incorrectly when used in a braced-init-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61857
Bug ID: 61857
Summary: An init-capturing lambda is parsed incorrectly when
used in a braced-init-list
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
struct A {
A(int val){}
};
int main()
{
A a{ [x=123]{ return x; }() };
}
init-capture2.cpp: In function ‘int main()’:
init-capture2.cpp:7:11: error: ‘x’ was not declared in this scope
A a{ [x=123]{ return x; }() };
Clang recently fixed this bug, for clang it was caused by the parser
getting confused with the lambda and designated initializers, perhaps
gcc has a similar bug. With parentheses the code works:
struct A {
A(int val){}
};
int main()
{
A a( [x=123]{ return x; }() );
}
[Bug c++/61857] An init-capturing lambda is parsed incorrectly when used in a braced-init-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61857 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-20 Ever confirmed|0 |1
[Bug go/61303] gccgo: segfault, regression since 4.8.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61303 --- Comment #2 from Maciej Bliziński maciej at opencsw dot org --- I've just reproduced this with gcc-4.9.1 (Solaris 10 sparc).
[Bug c/39134] front end does not reject sizeof on function types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39134 Chris Hennick christopherhe at trentu dot ca changed: What|Removed |Added CC||christopherhe at trentu dot ca --- Comment #2 from Chris Hennick christopherhe at trentu dot ca --- Shouldn't it at least raise a warning, even using the default invocation? To me, a positive sizeof(x) implies that x is an object that can be moved and copied, and from what I've read, some novice programmers seem to expect that to be true for compiled and loaded functions. Of course, an alternative would be to actually compile/link all sizeof'd functions in such a way that they *could* be moved and copied...
[Bug go/61303] gccgo: segfault, regression since 4.8.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61303 --- Comment #3 from Ian Lance Taylor ian at airs dot com --- Do you have a test case that I can use to reproduce the problem? Do you know whether the problem occurs on GNU/Linux?
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #28 from Dominique d'Humieres dominiq at lps dot ens.fr --- Created attachment 33158 [details] Reduced test case, 140 lines Further reduced to program main implicit none type :: string_t character(LEN=1), dimension(:), allocatable :: chars end type string_t type(string_t) :: prt_in integer :: i prt_in = string_t([W]) do i = 1, 16 print *, i call process_configuration (new_prt_spec ([prt_in])) end do contains elemental function new_prt_spec (name) result (prt_spec) type(string_t), intent(in) :: name type(string_t) :: prt_spec end function new_prt_spec subroutine process_configuration (prt_in) type(string_t), dimension(:), intent(in) :: prt_in end subroutine process_configuration end program main and it does not require iso_varying_string!-) With 4.9.0 it counts up to 16, while with 4.9.1 and 4.10 with/without the patch in comment 23 it gives 1 2 a.out(71763,0x7fff7bc1d310) malloc: *** error for object 0x7fe788e0: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug ...
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Dominyk Tiller dominyktiller at gmail dot com changed: What|Removed |Added CC||dominyktiller at gmail dot com --- Comment #13 from Dominyk Tiller dominyktiller at gmail dot com --- This remains an issue on the latest release of 4.9.1 - xgcc: warning: couldn’t understand kern.osversion ‘14.0.0 In file included from /usr/include/stdio.h:65:0, from ../../.././libgcc/../gcc/tsystem.h:87, from ../../.././libgcc/libgcc2.c:27: /usr/include/Availability.h:174:44: error: missing binary operator before token ( #if defined(__has_feature) __has_feature(attribute_availability_with_message) ^ In file included from /usr/include/stdio.h:65:0, from ../../.././libgcc/../gcc/tsystem.h:87, from ../../.././libgcc/libgcc2.c:27: /usr/include/Availability.h:184:44: error: missing binary operator before token ( #if defined(__has_feature) __has_feature(attribute_availability_app_extension) ^ make[5]: *** [_muldi3.o] Error 1 make[4]: *** [multi-do] Error 1 make[3]: *** [all-multi] Error 2 make[2]: *** [all-stage1-target-libgcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 The patch provided on 4.8.3 also doesn't apply to 4.9.1, which was pretty much expected. Is there status/timeline for folding in 10.10 support?
[Bug c/61854] Warning single-line comment for -std=c89?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61854 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-20 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Perhaps GCC should accept // without comment unless -Wpedantic. The current error is nonsensical.
[Bug fortran/61632] Memory corruption on error when writing formatted data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Attachment #33155|0 |1 is obsolete|| --- Comment #21 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Created attachment 33160 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33160action=edit Updated patch taking care of valgrind error This patch includes fixing the valgrind error by allocating and setting the NULL byte at the end of the format string.
[Bug fortran/61632] Memory corruption on error when writing formatted data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632 --- Comment #22 from Dominique d'Humieres dominiq at lps dot ens.fr --- Created attachment 33160 [details] Updated patch taking care of valgrind error This patch includes fixing the valgrind error by allocating and setting the NULL byte at the end of the format string. With this patch all my tests for this PR pass without problem: no more memory corruption and the caret is at the right position!-). I have two questions: (1) my understanding of offset = (j 60) ? j - 40 : 0; j -= offset; width = dtp-format_len - offset; is to set j to 40 and to decrease width by j-40 if j60. This part is now removed, should not we limit offset to something? (2) Do you need me to package one or two of my tests for the caret position? Indeed I'ld perfectly happy if the behavior reported in comment 10 would be at least understood. Note that with the code program p call ss0() call ss() end program p subroutine ss0 CHARACTER(3), save :: ZTYP(4) DATA ZTYP /'WWW','XXX','YYY','ZZZ'/ write(10,500,err=10,iostat=iosa) 'AAA','BBB',0.0,ZTYP 500 FORMAT(2(A3),1PE13.5,A3) return 10 write(10, *) write(10, *) 'iostat =', iosa end subroutine ss0 subroutine ss CHARACTER(3), save :: ZTYP(4) DATA ZTYP /'WWW','XXX','YYY','ZZZ'/ write(10,600) 'AAA','BBB',0.0,ZTYP 600 FORMAT(A3,1PE13.5,2(A3)) end subroutine ss gives at run time [Book15] f90/bug% cat fort.10 AAABBB 0.0E+00WWW iostat =5006 but my mother is saying le mieux est l'ennemi du bien (~ the best is against the good) so I think this should not defer the commit of the patch.
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #29 from Jürgen Reuter juergen.reuter at desy dot de --- A trivial workaround for the problem is to replace (In reply to Dominique d'Humieres from comment #28) Created attachment 33158 [details] Reduced test case, 140 lines Further reduced to program main implicit none type :: string_t character(LEN=1), dimension(:), allocatable :: chars end type string_t type(string_t) :: prt_in integer :: i prt_in = string_t([W]) do i = 1, 16 print *, i call process_configuration (new_prt_spec ([prt_in])) end do contains elemental function new_prt_spec (name) result (prt_spec) type(string_t), intent(in) :: name type(string_t) :: prt_spec end function new_prt_spec subroutine process_configuration (prt_in) type(string_t), dimension(:), intent(in) :: prt_in end subroutine process_configuration end program main and it does not require iso_varying_string!-) With 4.9.0 it counts up to 16, while with 4.9.1 and 4.10 with/without the patch in comment 23 it gives 1 2 a.out(71763,0x7fff7bc1d310) malloc: *** error for object 0x7fe788e0: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug ... A trivial workaround is to replace call process_configuration (new_prt_spec ([prt_in])) by call process_configuration ([new_prt_spec (prt_in)]) However, nevertheless you would want to understand why the elemental function causes a malloc crash for dim 1 arrays and works for scalars and dim 1 arrays as input.
[Bug middle-end/61853] [4.9,4.10 Regression] ICE: SIGSEGV in store_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61853 --- Comment #7 from John David Anglin danglin at gcc dot gnu.org --- Regarding the record type: (gdb) p debug_tree ((tree)0xfab48600) record_type 0xfab48600 Energy sizes-gimplified asm_written needs-constructing type_1 type_5 DF size integer_cst 0xfacf4378 type integer_type 0xfad06120 bitsizetype constant 64 unit size integer_cst 0xfacf4390 type integer_type 0xfad060c0 sizetype constant 8 align 64 symtab -145262192 alias set -1 canonical type 0xfab44d20 fields field_decl 0xf9ded720 rawValue_ type real_type 0xfad06ba0 double sizes-gimplified asm_written type_6 DF size integer_cst 0xfacf4378 64 unit size integer_cst 0xfacf4390 8 align 64 symtab -85994080 alias set 8 canonical type 0xfad06ba0 precision 64 pointer_to_this pointer_type 0xfad06cc0 reference_to_this reference_type 0xfa6f5f60 used private nonlocal decl_3 DF file ../include/ThePEG/Config/PhysicalQty.h line 162 col 10 size integer_cst 0xfacf4378 64 unit size integer_cst 0xfacf4390 8 align 64 offset_align 64 offset integer_cst 0xfacf4348 constant 0 bit offset integer_cst 0xfacf43a8 constant 0 context record_type 0xfab44d20 Qty chain type_decl 0xf9de8480 Qty type record_type 0xf9de84e0 Qty used external nonlocal suppress-debug decl_4 VOID file ../include/ThePEG/Config/PhysicalQty.h line 82 col 1 align 8 context record_type 0xfab44d20 Qty result record_type 0xfab44d20 Qty chain type_decl 0xf9deb420 Squared context namespace_decl 0xfad7ed20 ThePEG full-name ThePEG::Units::Energy needs-constructor X() X(constX) this=(X) n_parents=0 use_template=1 interface-unknown pointer_to_this pointer_type 0xf7ed7300 reference_to_this reference_type 0xf7f18a20 chain type_decl 0xfab48000 Qty $2 = void (gdb) p debug_tree ((tree)0xf7f1a980) function_decl 0xf7f1a980 _ZTv0_n64_NK6ThePEG23ConstituentParticleData15constituentMassEv type method_type 0xf7f13ba0 type record_type 0xfab48600 Energy sizes-gimplified asm_written needs-constructing type_1 type_5 DF size integer_cst 0xfacf4378 constant 64 unit size integer_cst 0xfacf4390 constant 8 align 64 symtab -145262192 alias set -1 canonical type 0xfab44d20 fields field_decl 0xf9ded720 rawValue_ context namespace_decl 0xfad7ed20 ThePEG full-name ThePEG::Units::Energy needs-constructor X() X(constX) this=(X) n_parents=0 use_template=1 interface-unknown pointer_to_this pointer_type 0xf7ed7300 reference_to_this reference_type 0xf7f18a20 chain type_decl 0xfab48000 Qty SI size integer_cst 0xfacf4318 constant 32 unit size integer_cst 0xfacf4330 constant 4 align 32 symtab 0 alias set -1 canonical type 0xf7f13c60 method basetype record_type 0xf7f135a0 ConstituentParticleData arg-types tree_list 0xf7f148b8 value pointer_type 0xf7f13c00 chain tree_list 0xfacf4b40 value void_type 0xfad06960 void pointer_to_this pointer_type 0xf7f1bd80 addressable used nothrow public ignored weak virtual decl_5 SI file ConstituentParticleData.h line 57 col 18 align 32 context record_type 0xf7f135a0 ConstituentParticleData initial block 0xf73f1d58 result result_decl 0xf71ef960 D.88242 type record_type 0xfab48600 Energy used ignored regdecl DF file ConstituentParticleData.h line 57 col 18 size integer_cst 0xfacf4378 64 unit size integer_cst 0xfacf4390 8 align 64 context function_decl 0xf7f1a980 _ZTv0_n64_NK6ThePEG23ConstituentParticleData15constituentMassEv (parallel:BLK [ (expr_list:REG_DEP_TRUE (reg:DI 101 [ retval ]) (const_int 0 [0])) ]) full-name virtual ThePEG::Units::Energy ThePEG::ConstituentParticleData::_ZTv0_n64_NK6ThePEG23ConstituentParticleData15constituentMassEv() const arguments parm_decl 0xf7f21f00 this type pointer_type 0xf7f13cc0 type record_type 0xf7f13b40 ConstituentParticleData readonly sizes-gimplified public unsigned SI size integer_cst 0xfacf4318 32 unit size integer_cst 0xfacf4330 4 align 32 symtab -157156016 alias set -1 canonical type 0xf7f13cc0 readonly used unsigned SI file ConstituentParticleData.h line 57 col 36 size integer_cst 0xfacf4318 32 unit size integer_cst 0xfacf4330 4 align 32 context function_decl 0xf7f1a980 _ZTv0_n64_NK6ThePEG23ConstituentParticleData15constituentMassEv (reg/f:SI 102 [ this ]) arg-type pointer_type 0xf7f13cc0 incoming-rtl (reg:SI 26 %r26 [ this ]) struct-function 0xf7880c98 I'm not sure I can answer your first question.
[Bug fortran/49802] [F2003, F2008] Wrong code with VALUE, F2008: VALUE with arrays/DIMENSION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49802 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- I also confirm that compiling the test in comment #5 gives an ICE I get the same ICE with the following code call pr53876 end subroutine pr53876 IMPLICIT NONE TYPE :: individual integer :: icomp ! Add an extra component to test offset REAL, DIMENSION(:), ALLOCATABLE :: genes END TYPE CLASS(individual), DIMENSION(:), ALLOCATABLE :: indv, indv1 allocate (indv(2), source = [individual(1, [99,999]), individual(2, [999,])]) ! allocate (indv1(2), source = [indv(1),indv(2)]) print *, fun([indv(1),indv(2)]) contains elemental function fun(x) result(res) integer :: res class(individual), intent(in) :: x res = x%genes(1) end END
[Bug c/61854] Warning single-line comment for -std=c89?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61854
Harald van Dijk harald at gigawatt dot nl changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #2 from Harald van Dijk harald at gigawatt dot nl ---
(In reply to Manuel López-Ibáñez from comment #1)
Perhaps GCC should accept // without comment unless -Wpedantic. The current
error is nonsensical.
The point of the -std=c89 option is that if a program is valid C89, GCC will
accept it in that mode. Extensions that don't conflict with the standard are
enabled without any diagnostic unless -pedantic is also passed. Extensions that
do conflict with the standard are disabled. // comments are an extension that
conflicts with the standard, so should not be enabled. A C89+extensions mode
already exists, that's what -std=gnu89 (the default mode) does. Example
program:
int main() {
return 1 //**/ 2
;
}
C89 requires this to return zero, and gcc -std=c89 does correctly make this
return zero. gcc -std=gnu89 makes this return 1. (More realistically, enabling
// comments could cause GCC to reject valid code as having syntax errors where
there are none.)
The request in this bug report does make sense to me: if GCC detects a syntax
error in c89 mode, and the syntax error is caused by an unexpected / token that
immediately follows another / token, it would make sense to treat that as a
special case. Handling it only when there is an error will not cause valid code
to be rejected.
[Bug fortran/61632] Memory corruption on error when writing formatted data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632 --- Comment #23 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #22) (1) my understanding of offset = (j 60) ? j - 40 : 0; j -= offset; width = dtp-format_len - offset; is to set j to 40 and to decrease width by j-40 if j60. This part is now removed, should not we limit offset to something? Yes, I would like to first commit the patch and then work on this additional part. Ideally, if we have a long format string and the error occurs beyond a typical line length of 80 we should 'slide' the view of the format string and the carat along so the user can see where and in what context. Very doable, now that we have the other problem taken care of. Your other question I am still thinking about. ;)
[Bug fortran/61632] Memory corruption on error when writing formatted data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632 --- Comment #24 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sun Jul 20 20:03:41 2014 New Revision: 212875 URL: https://gcc.gnu.org/viewcvs?rev=212875root=gccview=rev Log: 2014-07-20 Jerry DeLisle jvdeli...@gcc.gnu.org PR libgfortran/61632 * io/format.c (format_error): Avoid invalid string pointer by using the fortran string length values to generate error string. (parse_format): Allocate the null terminator for the format string. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c
[Bug middle-end/61858] New: GNAT BUG: in store_field, at expr.c:6591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61858 Bug ID: 61858 Summary: GNAT BUG: in store_field, at expr.c:6591 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu Created attachment 33161 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33161action=edit Ada files gcc-4.9 -c -g -O2 -gnatafno -gnatVa -I- -gnatA /home/dave/debian/libxmlada/libxm lada-4.4.0puregpl/dom/dom-core-nodes.adb +===GNAT BUG DETECTED==+ | 4.9.0 (hppa-linux-gnu) in store_field, at expr.c:6591| | Error detected around /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/schem a/schema-validators.adb:246:13| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc-4.9 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format || (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/schema/schema-validators.adb /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/debian/build_obj_static/GNAT-TEMP-01.TMP /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/debian/build_obj_static/GNAT-TEMP-02.TMP /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/schema/schema-validators.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/schema/schema.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/unicode/unicode.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/unicode/unicode-ces.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/sax/sax.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/sax/sax-htable.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/sax/sax-locators.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/sax/sax-symbols.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/sax/sax-pointers.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/sax/sax-readers.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/input_sources/input_sources.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/unicode/unicode-ces-basic_8bit.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/unicode/unicode-ces-utf32.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/unicode/unicode-ccs.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/sax/sax-exceptions.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/sax/sax-attributes.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/sax/sax-models.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/sax/sax-utils.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/sax/sax-state_machines.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/schema/schema-simple_types.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/schema/schema-decimal.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/schema/schema-date_time.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/schema/schema-validators-xsd_grammar.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/sax/sax-symbols.adb /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/sax/sax-pointers.adb /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/sax/sax-state_machines.adb /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/sax/sax-htable.adb /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/sax/sax-utils.adb /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/sax/sax-encodings.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/unicode/unicode-ces-utf8.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/unicode/unicode-names.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/unicode/unicode-names-basic_latin.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/schema/schema-simple_types.adb /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/schema/schema.adb /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/sax/sax-readers.adb /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/input_sources/input_sources-file.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/input_sources/input_sources-strings.ads /home/dave/debian/libxmlada/libxmlada-4.4.0puregpl/unicode/unicode.adb raised TYPES.UNRECOVERABLE_ERROR :
[Bug middle-end/61853] [4.9,4.10 Regression] ICE: SIGSEGV in store_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61853 --- Comment #8 from John David Anglin danglin at gcc dot gnu.org --- PR 61858 may be related, or possibly a duplicate of this bug.
[Bug c++/61859] New: extra character in match of std::regex_match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61859
Bug ID: 61859
Summary: extra character in match of std::regex_match
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: stick at gk2 dot sk
Testcase:
// g++ ./regex_test.cpp -std=c++11 -o ./regex_test ./regex_test
#include iostream
#include string
#include regex
int main()
{
std::string s = /call/123;
std::regex r = std::regex(/call/(.+));
std::smatch mr;
bool m = std::regex_match(s, mr, r);
std::cout m std::endl; // prints 1, OK
std::cout mr[0] std::endl; // prints /call/123, OK
std::cout mr[1] std::endl; // prints /123, expected 123
return 0;
}
[Bug c++/59873] The value of char32_t U'\u0000' and char16_t u'\u0000' is 1, instead of 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873 Richard Smith richard-gccbugzilla at metafoo dot co.uk changed: What|Removed |Added CC||richard-gccbugzilla@metafoo ||.co.uk --- Comment #11 from Richard Smith richard-gccbugzilla at metafoo dot co.uk --- This looks like a duplicate of bug 53690.
[Bug c++/44122] Confusing error: cannot convert 'T*' to 'T*' (when T are different scopes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44122
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #5 from Paul Pluzhnikov ppluzhnikov at google dot com ---
GCC output @r212875:
svn-r212875/bin/g++ -c t.cc
t.cc: In function ‘int bar()’:
t.cc:8:18: error: cannot convert ‘Py_ssize_t* {aka int*}’ to ‘Py_ssize_t* {aka
long int*}’ for argument ‘1’ to ‘int foo(Py_ssize_t*)’
return foo(pos);
^
[Bug c++/59832] [c++11] ICE in reshape_init_class with initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832 --- Comment #6 from Paul Pluzhnikov ppluzhnikov at google dot com --- Still broken @r212875
[Bug c++/59815] Apparently bogus error: 'Outer' is already declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59815 --- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com --- Still broken @r212875
[Bug middle-end/59812] Missing aggressive loop optimization warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59812 --- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com --- Reconfirmed @r212875
[Bug rtl-optimization/61799] [4.6/4.7 regression][ia64] r165240 caused GDB stops with SIGTRAP at 0 address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61799 --- Comment #2 from Émeric MASCHINO emeric.maschino at gmail dot com --- (In reply to Richard Biener from comment #1) Please try at least GCC 4.8 - both 4.6 and 4.7 are no longer supported. GCC 4.8 is fine, thanks. I've tracked down the commit that fixed all of this to revision 191928, aiming to fix PR rtl-optimization/54457 [2]. Back to the original GDB issue, can it now be explained (breakage and fix) by retrospectively looking at the code modified by revisions 165240 and 191928? Or does it make no sense at all and I'm simply observing random side-effects of some more subtle breakage elsewhere? Émeric [1] https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=191928 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54457
[Bug target/61359] GCC Bootstrap comparison failures on hppa2.0w-hp-hpux11.23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61359 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #3 from John David Anglin danglin at gcc dot gnu.org --- What is your bootstrap compiler? Check build log as to why UINT64_C is not defined? GCC provides include fixes and stdint.h, etc. So, the error you mention should not occur when building with recent GCC version. Try building just C and C++. Disable libquadmath build until you have working GCC compiler (I would say 4.7 or later).
[Bug target/61656] Undefined behavior in classify_argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61656 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug c++/61860] New: Internal compiler error Killed (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61860 Bug ID: 61860 Summary: Internal compiler error Killed (program cc1plus) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dave at daveolday dot com Created attachment 33162 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33162action=edit Internal compiler error During compile of gnuradio using pybombs the procedure gets to one file and dies with the above message. Here's the output from the script... /home/debian/pybombs/src/gnuradio/build/gr-digital/swig/digital_swigPYTHON_wrap.cxx: In function ‘void init_digital_swig()’: /home/debian/pybombs/src/gnuradio/build/gr-digital/swig/digital_swigPYTHON_wrap.cxx:243666:21: warning: variable ‘md’ set but not used [-Wunused-but-set-variable] g++: internal compiler error: Killed (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions. make[2]: *** [gr-digital/swig/CMakeFiles/_digital_swig.dir/digital_swigPYTHON_wrap.cxx.o] Error 4 make[1]: *** [gr-digital/swig/CMakeFiles/_digital_swig.dir/all] Error 2 make: *** [all] Error 2
[Bug c++/61860] Internal compiler error Killed (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61860 --- Comment #1 from Mikael Pettersson mikpelinux at gmail dot com --- You ran out of RAM during the g++ job so the kernel killed it. You need more RAM (preferably), or to add some swap (unpleasant but sometimes necessary).
[Bug libstdc++/53631] [C++11] regex is unimplemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||stick at gk2 dot sk --- Comment #19 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 61859 has been marked as a duplicate of this bug. ***
[Bug c++/61859] extra character in match of std::regex_match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61859 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- regex is not implemented in gcc 4.8 why are you even using gcc 4.8.0? at least use 4.8.3, or 4.9.1 if you want regex *** This bug has been marked as a duplicate of bug 53631 ***
[Bug c/61861] New: Incorrect column number for -Wdiscarded-qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61861
Bug ID: 61861
Summary: Incorrect column number for -Wdiscarded-qualifiers
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
It seems that GCC outputs incorrect column number for __FILE__, but not user
defined macro T.
$: cat t.c
extern int * f (int*a, char * loc);
#define T t.c
void g(int *a) {
f(a, T);/*column number here is correct*/
f(a, __FILE__); /*column number here is INCORRECT*/
}
$:
$: gcc-trunk -Wwrite-strings -c t.c
t.c: In function ‘g’:
t.c:3:11: warning: passing argument 2 of ‘f’ discards ‘const’ qualifier from
pointer target type [-Wdiscarded-qualifiers]
#define T t.c
^
t.c:6:8: note: in expansion of macro ‘T’
f(a, T);
^
t.c:1:14: note: expected ‘char *’ but argument is of type ‘const char *’
extern int * f (int*a, char * loc);
^
t.c:7:1: warning: passing argument 2 of ‘f’ discards ‘const’ qualifier from
pointer target type [-Wdiscarded-qualifiers]
f(a, __FILE__);
^
t.c:1:14: note: expected ‘char *’ but argument is of type ‘const char *’
extern int * f (int*a, char * loc);
^
$:
$: clang-trunk -Wwrite-strings -c t.c
t.c:6:8: warning: passing 'const char [4]' to parameter of type 'char *'
discards qualifiers
[-Wincompatible-pointer-types-discards-qualifiers]
f(a, T);
^
t.c:3:11: note: expanded from macro 'T'
#define T t.c
^
t.c:1:31: note: passing argument to parameter 'loc' here
extern int * f (int*a, char * loc);
^
t.c:7:8: warning: passing 'const char [4]' to parameter of type 'char *'
discards qualifiers
[-Wincompatible-pointer-types-discards-qualifiers]
f(a, __FILE__);
^~~~
scratch space:2:1: note: expanded from here
t.c
^
t.c:1:31: note: passing argument to parameter 'loc' here
extern int * f (int*a, char * loc);
^
2 warnings generated.
$:
[Bug c/61862] New: No -Wcast-align warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61862
Bug ID: 61862
Summary: No -Wcast-align warning
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
GCC does not emit cast-align warning on the following code. Is this expected?
$: cat t.c
int *f(char * c, int n) {
return (int *)(c + 2);
}
$: clang-trunk -Wcast-align -c t.c
t.c:2:10: warning: cast from 'char *' to 'int *' increases required alignment
from 1 to 4 [-Wcast-align]
return (int *)(c + 2);
^~
1 warning generated.
$: gcc-trunk -Wcast-align -c t.c
$:
[Bug c++/61863] New: Data corruption when creating temporary object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61863 Bug ID: 61863 Summary: Data corruption when creating temporary object Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mehta at roguewave dot com Created attachment 33163 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33163action=edit ustrTst.cpp, MyUStr.h Hi, We are seeing data corruption with gcc 4.8. This problem happens when optimization is 03 or greater. It appears to occur when a temporary object is created using move constructor. Also, this problem doesn't happen with gcc 4.9. Compile and Link Line: ulimit -St 600 g++ -m64 -msse3 -O3 -pthread --pedantic -Wall -W -Wno-long-long -std=gnu++11 -I. -c ustrTst.cpp ulimit -St 600 g++ -m64 -pthread -o ustrTstustrTst.o -lm -ldl I have attached the test case. Thanks, Vikas
[Bug c/61864] New: Feature Request, -Wcovered-switch-default to identify dead default branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61864
Bug ID: 61864
Summary: Feature Request, -Wcovered-switch-default to identify
dead default branch
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
Currently, GCC supports -Wswitch and -Wswitch-enum. But it does not warn on the
case that all the possible values of an enum are covered in a switch, making
the default branch unreachable.
The following code is extracted and simplified from the SPEC benchmark, the
enum only has three values, which are all covered in the switch. Therefore the
default branch is dead.
$: cat t.c
enum clust_strategy {
CLUSTER_MEAN, CLUSTER_MAX, CLUSTER_MIN
};
int Cluster(enum clust_strategy mode) {
switch(mode) {
case CLUSTER_MEAN: break;
case CLUSTER_MAX: break;
case CLUSTER_MIN: break;
default: break;
}
return 0;
}
$: clang-trunk -Wcovered-switch-default -c t.c
t.c:10:3: warning: default label in switch which covers all enumeration values
[-Wcovered-switch-default]
default: break;
^
1 warning generated.
$:
libgo patch committed: Mark varargs function no_split_stack for Clang
This patch from Peter Collingbourne marks the varargs function runtime_sprintf as no_split_stack when using Clang. Apparently Clang does not support split-stack for varargs function. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian diff -r ca381cdd378c libgo/runtime/print.c --- a/libgo/runtime/print.c Sat Jul 19 14:35:30 2014 -0700 +++ b/libgo/runtime/print.c Sun Jul 20 02:13:45 2014 -0700 @@ -76,9 +76,15 @@ // x86-64. Note that signal handlers receive slightly less stack space than they // would normally do if they happen to be called while this function is being // run. If this turns out to be a problem we could consider increasing BACKOFF. + void runtime_printf(const char *s, ...) __attribute__((no_split_stack)); + +int32 +runtime_snprintf(byte *buf, int32 n, const char *s, ...) +__attribute__((no_split_stack)); + #endif void
[PATCH, i386, PR61827] Fix fuse-caller-save-xmm.c test-case
Uros,
this patch fixes the problems in test-case
gcc.target/i386/fuse-caller-save-xmm.c reported in PR 61827. I've removed the
checks for cfi_def_cfa_offset, which were not robust enough for the different
configurations.
Furthermore, I've:
- added checks for all insns that handle the xmm registers, to make sure we're
actually using the xmm1 register.
- fixed the scan-assembler-not lines to allow both %esp and %rsp.
- removed main, which was really only intended for the
fuse-caller-save-xmm-run.c test-case.
Tested with -m32 and -m64.
OK for trunk?
Thanks,
- Tom
2014-07-20 Tom de Vries t...@codesourcery.com
PR target/61827
* gcc.target/i386/fuse-caller-save-xmm.c: Add checks for insns with xmm
registers. Remove cfi_def_cfa_offset checks. Generalize checks
containing %rsp.
(main): Remove.
diff --git a/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c b/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
index ff21f0c..3754b01 100644
--- a/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
+++ b/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
@@ -15,23 +15,12 @@ foo (v2df y)
return y + bar (y);
}
-int
-main (void)
-{
- int success;
- union {
-v2df v;
-double d[2];
- } u;
-
- u.v = foo ((v2df){ 5.0, 5.0});
- success = (u.d[0] == 13.0
- u.d[1] == 13.0);
-
- return !success;
-}
+/* Check presence of all insns on xmm registers. These checks are expected to
+ pass with both -fuse-caller-save and -fno-use-caller-save. */
+/* { dg-final { scan-assembler-times addpd\t\\.LC0.*, %xmm0 1 } } */
+/* { dg-final { scan-assembler-times addpd\t%xmm1, %xmm0 1 } } */
+/* { dg-final { scan-assembler-times movapd\t%xmm0, %xmm1 1 } } */
-/* { dg-final { scan-assembler-not movaps\t%xmm1, \\(%rsp\\) } } */
-/* { dg-final { scan-assembler-not movapd\t\\(%rsp\\), %xmm1 } } */
-/* { dg-final { scan-assembler-times .cfi_def_cfa_offset 16 1 } } */
-/* { dg-final { scan-assembler-times .cfi_def_cfa_offset 32 1 } } */
+/* Check absence of save/restore of xmm1 register. */
+/* { dg-final { scan-assembler-not movaps\t%xmm1, \\(%.sp\\) } } */
+/* { dg-final { scan-assembler-not movapd\t\\(%.sp\\), %xmm1 } } */
[C PATCH] Better location for implicit_decl_warning (PR c/61852)
implicit_decl_warning wasn't getting a location, so the column info
was poor. It's easy to fix this up.
Bootstrapped/regtested on x86_64-linux, applying to trunk.
2014-07-20 Marek Polacek pola...@redhat.com
PR c/61852
* c-decl.c (implicit_decl_warning): Add location_t parameter. Use it.
(implicitly_declare): Pass location to implicit_decl_warning.
* gcc.dg/pr61852.c: New test.
diff --git gcc/c/c-decl.c gcc/c/c-decl.c
index 0ca2e0d..425fc58 100644
--- gcc/c/c-decl.c
+++ gcc/c/c-decl.c
@@ -2951,18 +2951,18 @@ pushdecl_top_level (tree x)
}
static void
-implicit_decl_warning (tree id, tree olddecl)
+implicit_decl_warning (location_t loc, tree id, tree olddecl)
{
if (warn_implicit_function_declaration)
{
bool warned;
if (flag_isoc99)
- warned = pedwarn (input_location, OPT_Wimplicit_function_declaration,
+ warned = pedwarn (loc, OPT_Wimplicit_function_declaration,
implicit declaration of function %qE, id);
else
- warned = warning (OPT_Wimplicit_function_declaration,
- G_(implicit declaration of function %qE), id);
+ warned = warning_at (loc, OPT_Wimplicit_function_declaration,
+G_(implicit declaration of function %qE), id);
if (olddecl warned)
locate_old_decl (olddecl);
}
@@ -3015,7 +3015,7 @@ implicitly_declare (location_t loc, tree functionid)
then recycle the old declaration but with the new type. */
if (!C_DECL_IMPLICIT (decl))
{
- implicit_decl_warning (functionid, decl);
+ implicit_decl_warning (loc, functionid, decl);
C_DECL_IMPLICIT (decl) = 1;
}
if (DECL_BUILT_IN (decl))
@@ -3052,7 +3052,7 @@ implicitly_declare (location_t loc, tree functionid)
DECL_EXTERNAL (decl) = 1;
TREE_PUBLIC (decl) = 1;
C_DECL_IMPLICIT (decl) = 1;
- implicit_decl_warning (functionid, 0);
+ implicit_decl_warning (loc, functionid, 0);
asmspec_tree = maybe_apply_renaming_pragma (decl, /*asmname=*/NULL);
if (asmspec_tree)
set_user_assembler_name (decl, TREE_STRING_POINTER (asmspec_tree));
diff --git gcc/testsuite/gcc.dg/pr61852.c gcc/testsuite/gcc.dg/pr61852.c
index e69de29..f488aca 100644
--- gcc/testsuite/gcc.dg/pr61852.c
+++ gcc/testsuite/gcc.dg/pr61852.c
@@ -0,0 +1,10 @@
+/* PR c/61852 */
+/* { dg-do compile } */
+/* { dg-options -Wimplicit-function-declaration } */
+
+int
+f (int a)
+{
+ int b = a + a + a + ff (a); /* { dg-warning 23:implicit declaration of
function } */
+ return b;
+}
Marek
Re: [GSoC] Addition of ISL AST generation to Graphite
I am not aware of any problems with isl 0.12 and would be surprised if such
problems exist. Are you?
I'm not aware of them, too.
P.S: As Richard suggested, we may also want to forbid CLooG 0.17.
I've attached the patch, which adds the requirement for ClooG 0.18.1.
Is it fine for trunk?
--
Cheers, Roman Gareev.
2014-07-20 Roman Gareev gareevro...@gmail.com
* configure.ac: Accept only CLooG 0.18.1.
* configure: Regenerate.
Index: configure
===
--- configure (revision 212861)
+++ configure (working copy)
@@ -6031,8 +6031,8 @@
CFLAGS=${_cloog_saved_CFLAGS} ${clooginc} ${islinc} ${gmpinc}
LDFLAGS=${_cloog_saved_LDFLAGS} ${clooglibs} ${isllibs} ${gmplib}
-{ $as_echo $as_me:${as_lineno-$LINENO}: checking for version 0.17.0 of
CLooG 5
-$as_echo_n checking for version 0.17.0 of CLooG... 6; }
+{ $as_echo $as_me:${as_lineno-$LINENO}: checking for version 0.18.1 of
CLooG 5
+$as_echo_n checking for version 0.18.1 of CLooG... 6; }
cat confdefs.h - _ACEOF conftest.$ac_ext
/* end confdefs.h. */
#include cloog/version.h
@@ -6040,50 +6040,8 @@
main ()
{
#if CLOOG_VERSION_MAJOR != 0 \
-|| CLOOG_VERSION_MINOR != 17 \
-|| CLOOG_VERSION_REVISION 0
-choke me
- #endif
- ;
- return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile $LINENO; then :
- gcc_cv_cloog=yes
-else
- gcc_cv_cloog=no
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-{ $as_echo $as_me:${as_lineno-$LINENO}: result: $gcc_cv_cloog 5
-$as_echo $gcc_cv_cloog 6; }
-
-CFLAGS=$_cloog_saved_CFLAGS
-LDFLAGS=$_cloog_saved_LDFLAGS
- fi
-
-
-if test ${gcc_cv_cloog} = no ; then
-
-
-
- if test ${ENABLE_CLOOG_CHECK} = yes ; then
-_cloog_saved_CFLAGS=$CFLAGS
-_cloog_saved_LDFLAGS=$LDFLAGS
-
-CFLAGS=${_cloog_saved_CFLAGS} ${clooginc} ${islinc} ${gmpinc}
-LDFLAGS=${_cloog_saved_LDFLAGS} ${clooglibs} ${isllibs} ${gmplib}
-
-{ $as_echo $as_me:${as_lineno-$LINENO}: checking for version 0.18.0 of
CLooG 5
-$as_echo_n checking for version 0.18.0 of CLooG... 6; }
-cat confdefs.h - _ACEOF conftest.$ac_ext
-/* end confdefs.h. */
-#include cloog/version.h
-int
-main ()
-{
-#if CLOOG_VERSION_MAJOR != 0 \
|| CLOOG_VERSION_MINOR != 18 \
-|| CLOOG_VERSION_REVISION 0
+|| CLOOG_VERSION_REVISION 1
choke me
#endif
;
@@ -6104,7 +6062,6 @@
fi
-fi
Index: configure.ac
===
--- configure.ac(revision 212861)
+++ configure.ac(working copy)
@@ -1661,10 +1661,7 @@
dnl with user input.
CLOOG_INIT_FLAGS
dnl The versions of CLooG that work for Graphite.
-CLOOG_CHECK_VERSION(0,17,0)
-if test ${gcc_cv_cloog} = no ; then
- CLOOG_CHECK_VERSION(0,18,0)
-fi
+CLOOG_CHECK_VERSION(0,18,1)
dnl Only execute fail-action, if CLooG has been requested.
CLOOG_IF_FAILED([
[GSoC] A formatting issue.
This patch fixes a formatting issue related to the number of
characters in the line. Is it fine for trunk?
--
Cheers, Roman Gareev.
2014-07-20 Roman Gareev gareevro...@gmail.com
gcc/
* graphite-isl-ast-to-gimple.c:
Fixes a formatting issue related to the number of characters in the
line.
Index: gcc/graphite-isl-ast-to-gimple.c
===
--- gcc/graphite-isl-ast-to-gimple.c(revision 212863)
+++ gcc/graphite-isl-ast-to-gimple.c(working copy)
@@ -464,7 +464,8 @@
case isl_ast_op_lt:
{
// (iterator ub) = (iterator = ub - 1)
-isl_val *one = isl_val_int_from_si (isl_ast_expr_get_ctx (for_cond),
1);
+isl_val *one =
+ isl_val_int_from_si (isl_ast_expr_get_ctx (for_cond), 1);
isl_ast_expr *ub = isl_ast_expr_get_op_arg (for_cond, 1);
res = isl_ast_expr_sub (ub, isl_ast_expr_from_val (one));
break;
Re: [GSoC] A formatting issue.
On July 20, 2014 1:39:08 PM CEST, Roman Gareev gareevro...@gmail.com wrote: This patch fixes a formatting issue related to the number of characters in the line. Is it fine for trunk? Yes. That's an obvious fix. In case you feel a patch is obvious and it only touches graphite. Feel free to commit directly and to then send the patch for information to gcc-patches and to add me in cc. Thanks Tobias -- Cheers, Roman Gareev.
Re: [GSoC] Addition of ISL AST generation to Graphite
On July 20, 2014 1:29:30 PM CEST, Roman Gareev gareevro...@gmail.com wrote: I am not aware of any problems with isl 0.12 and would be surprised if such problems exist. Are you? I'm not aware of them, too. P.S: As Richard suggested, we may also want to forbid CLooG 0.17. I've attached the patch, which adds the requirement for ClooG 0.18.1. Is it fine for trunk? Great. Yes, I think it's fine for trunk. Tobias -- Cheers, Roman Gareev. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
libgo patch committed: Add missing import
This patch from Peter Collingbourne adds a missing import to a libgo test. The Go frontend should have detected this error. The patch for that is forthcoming (http://codereview.appspot.com/116960043) and I am adding a test case to the testsuite (http://codereview.appspot.com/11843). Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian diff -r f75db1811715 libgo/go/runtime/runtime_test.go --- a/libgo/go/runtime/runtime_test.go Sun Jul 20 02:23:52 2014 -0700 +++ b/libgo/go/runtime/runtime_test.go Sun Jul 20 08:08:27 2014 -0700 @@ -9,7 +9,7 @@ // io/ioutil // os // os/exec - // . runtime + . runtime runtime/debug // strconv // strings
Go patch committed: Don't merge dot-import names
This patch to the Go frontend fixes it so that a name included because
of a dot import (import . package) is not merged with the same name
defined in an earlier file. Without this patch, the Go compiler would
incorrectly accept code that used a name defined by a dot import in a
later file. I've sent out a change to add a test to the master
testsuite: http://codereview.appspot.com/11843 . For this patch,
bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r 0e313c250b05 go/gogo.cc
--- a/go/gogo.cc Sun Jul 20 08:08:44 2014 -0700
+++ b/go/gogo.cc Sun Jul 20 08:11:43 2014 -0700
@@ -473,7 +473,7 @@
bindings-begin_declarations();
p != bindings-end_declarations();
++p)
- this-add_named_object(p-second);
+ this-add_dot_import_object(p-second);
}
else if (ln == _)
package-set_uses_sink_alias();
@@ -1968,11 +1968,32 @@
return Named_object::make_sink();
}
-// Add a named object.
+// Add a named object for a dot import.
void
-Gogo::add_named_object(Named_object* no)
-{
+Gogo::add_dot_import_object(Named_object* no)
+{
+ // If the name already exists, then it was defined in some file seen
+ // earlier. If the earlier name is just a declaration, don't add
+ // this name, because that will cause the previous declaration to
+ // merge to this imported name, which should not happen. Just add
+ // this name to the list of file block names to get appropriate
+ // errors if we see a later definition.
+ Named_object* e = this-package_-bindings()-lookup(no-name());
+ if (e != NULL e-package() == NULL)
+{
+ if (e-is_unknown())
+ e = e-resolve();
+ if (e-package() == NULL
+ (e-is_type_declaration()
+ || e-is_function_declaration()
+ || e-is_unknown()))
+ {
+ this-add_file_block_name(no-name(), no-location());
+ return;
+ }
+}
+
this-current_bindings()-add_named_object(no);
}
diff -r 0e313c250b05 go/gogo.h
--- a/go/gogo.h Sun Jul 20 08:08:44 2014 -0700
+++ b/go/gogo.h Sun Jul 20 08:11:43 2014 -0700
@@ -397,7 +397,7 @@
// Add a named object to the current namespace. This is used for
// import . package.
void
- add_named_object(Named_object*);
+ add_dot_import_object(Named_object*);
// Add an identifier to the list of names seen in the file block.
void
diff -r 0e313c250b05 go/import.cc
--- a/go/import.cc Sun Jul 20 08:08:44 2014 -0700
+++ b/go/import.cc Sun Jul 20 08:11:43 2014 -0700
@@ -431,7 +431,7 @@
Typed_identifier tid(name, type, this-location_);
Named_object* no = this-package_-add_constant(tid, expr);
if (this-add_to_globals_)
-this-gogo_-add_named_object(no);
+this-gogo_-add_dot_import_object(no);
}
// Import a type.
@@ -464,7 +464,7 @@
Named_object* no;
no = this-package_-add_variable(name, var);
if (this-add_to_globals_)
-this-gogo_-add_named_object(no);
+this-gogo_-add_dot_import_object(no);
}
// Import a function into PACKAGE. PACKAGE is normally
@@ -518,7 +518,7 @@
{
no = package-add_function_declaration(name, fntype, loc);
if (this-add_to_globals_)
- this-gogo_-add_named_object(no);
+ this-gogo_-add_dot_import_object(no);
}
return no;
}
diff -r 0e313c250b05 go/unsafe.cc
--- a/go/unsafe.cc Sun Jul 20 08:08:44 2014 -0700
+++ b/go/unsafe.cc Sun Jul 20 08:11:43 2014 -0700
@@ -66,7 +66,7 @@
fntype-set_is_builtin();
no = bindings-add_function_declaration(Sizeof, package, fntype, bloc);
if (add_to_globals)
-this-add_named_object(no);
+this-add_dot_import_object(no);
// Offsetof.
results = new Typed_identifier_list;
@@ -76,7 +76,7 @@
fntype-set_is_builtin();
no = bindings-add_function_declaration(Offsetof, package, fntype, bloc);
if (add_to_globals)
-this-add_named_object(no);
+this-add_dot_import_object(no);
// Alignof.
results = new Typed_identifier_list;
@@ -86,7 +86,7 @@
fntype-set_is_builtin();
no = bindings-add_function_declaration(Alignof, package, fntype, bloc);
if (add_to_globals)
-this-add_named_object(no);
+this-add_dot_import_object(no);
if (!this-imported_unsafe_)
{
Go testsuite patch committed: compiledir fix
This patch to the Go testsuite driver adds support for having multiple
files in a single package for a compiledir test. Ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
2014-07-20 Ian Lance Taylor i...@google.com
* go.test/go-test.exp (go-gc-tests): Support multiple files in one
package for compiledir tests.
Index: go-test.exp
===
--- go-test.exp (revision 212213)
+++ go-test.exp (working copy)
@@ -651,13 +651,17 @@ proc go-gc-tests { } {
set runtests go-test.exp
set dg-do-what-default assemble
set dir [file rootname $test].dir
- set del {}
- foreach f [lsort [glob $dir/*.go]] {
- dg-test -keep-output $f -O -w $DEFAULT_GOCFLAGS
- lappend del [file rootname [file tail $f]].o
- }
- foreach f $del {
- file delete $f
+ set files [lsort [glob $dir/*.go]]
+ set packages [go-find-packages $test $name $files]
+ if { [llength $packages] 0 } {
+ set del [list]
+ foreach p $packages {
+ dg-test -keep-output [lindex $p 1] [lrange $p 2 end] -O -w $DEFAULT_GOCFLAGS
+ lappend del [file rootname [file tail [lindex $p 1]]].o
+ }
+ foreach f $del {
+ file delete $f
+ }
}
set runtests $hold_runtests
} elseif { $test_line == // rundir } {
[PING] Re: Abstract incremental hashing
Andi Kleen a...@firstfloor.org writes: This patchkit abstracts incremental hashing in tree.c and lto.c to make it easier to plug in new and more efficient hash algorithms. Right now it uses the old hash algorithms. So it's just a cleanup. Passes bootstrap and testing on x86_64-linux. Ping! Could someone review/approve this please? The patchkit touches quite a few places in tree.c/lto.c and if ok I would prefer to commit it relatively quickly to avoid conflicting with other changes. Thanks, -Andi
RE: Re: [MIPS r5900] libgcc floating point fixes
Jürgen Urban juergenur...@gmx.de writes:
Hello Richard,
Jürgen Urban juergenur...@gmx.de writes:
The problem happens with the r5900 hard float configurations, e.g.:
configure --target=mipsel-linux-gnu --with-float=hard --with-fpu=single
--with-arch=r5900
I created the attached patch which fixes this problem for r5900 and
another problem explained later.
The fixed code generates the following code which should be correct
(mipsr5900el-ps2-elf):
00105440 __extendsfdf2:
105440: 27bdffc8addiu sp,sp,-56
105444: 27a40028addiu a0,sp,40
105448: 27a50018addiu a1,sp,24
10544c: afbf0034sw ra,52(sp)
105450: 0c0417b5jal 105ed4 __unpack_f
105454: e7ac0028swc1$f12,40(sp)
105458: 8fa20024lw v0,36(sp)
10545c: 8fa40018lw a0,24(sp)
105460: 8fa5001clw a1,28(sp)
105464: 8fa60020lw a2,32(sp)
105468: 00021882srl v1,v0,0x2
10546c: 00021780sll v0,v0,0x1e
105470: afa20010sw v0,16(sp)
105474: 0c041789jal 105e24 __make_dp
105478: afa30014sw v1,20(sp)
10547c: 8fbf0034lw ra,52(sp)
105480: 03e8jr ra
105484: 27bd0038addiu sp,sp,56
The default targets mipsr5900el and mips64r5900el are not affected by
the problem, because soft float is the default.
It also seems that the same problem occurs with the following
configuration:
configure --target=mipsel-linux-gnu --with-float=hard --with-fpu=single
I expected that this combination should work and a problem should
already be detected. Can somebody confirm that the problem also occurs
with default mipsel?
Although that configuration is in theory supported by GCC (said like that
because I don't know the state of the glibc support for single-float),
I don't think anyone uses it for any target other than r5900. But you're
right that this is a --with-fpu=single thing rather than an r5900 thing,
so I don't think the patch is correct. It should be keyed off whether
the target is single-float or double-float, which you can test by
checking whether the preprocessor macro __mips_single_float is defined.
Checking these macros seem to be too late, because it needs to be known at
configure time and not at build time. The libgcc doesn't seem to be very
I believe the suggestion is to add some code to configure.ac to detect a
single-float configuration like the hard-float is detected and update your
patch accordingly with no need to reference r5900 at all:
case ${host} in
mips*-*-*)
AC_CACHE_CHECK([whether the target is hard-float],
[libgcc_cv_mips_hard_float],
[AC_COMPILE_IFELSE(
[#ifndef __mips_hard_float
#error FOO
#endif],
[libgcc_cv_mips_hard_float=yes],
[libgcc_cv_mips_hard_float=no])])
esac
I will check if I get something working.
flexible. It doesn't seem to provide different libraries for single and
Single and double float would need to be supported as multilibs, it is
generally
assumed that all libraries in the same folder follow a compatible ABI. Single
and double float ABIs are inherently incompatible.
double float. The Linux kernel on the PS2 has support to switch between
single and double float. For single float the hardware FPU is used and for
Just to confirm... The kernel has special handling for an ELF using r5900 arch
and then checks to see if it is single or double float?
Yes, for checking for r5900 I have an implementation. I don't have an
implementation for single and double float detection.
Is this something you
have recently developed outside of the mainline kernel or does it already
exist.
I'm not aware of such logic in the MIPS kernel yet.
Yes, this is developed in my kernel which currently is still based on Linux
2.6.35.4. I added a TIF_R5900FPU flag to thread_info.h. I plan that this will
get part of the mainline kernel. As the patch is too large to get accepted, I
need to change the binutils, so that sync.p will be added after or before the
right instruction automatically.
double the FPU emulator gets activated. Currently it only checks whether the
architecture is mips r5900 or not. For non r5900 the FPU emulator is
activated. It seems that we also need to add something to the ELF file to
specify the 32 bit or 64 bit for float. It would be good when it is not at a
so complicated position as the soft vs hard float flag, because it needs to
be read by the kernel when starting a ELF file. This way it would also be
I have a series of patches that will add this kind of support to the MIPS
ABI in the coming weeks for
Re: [Patch] PR55189 enable -Wreturn-type by default
Joseph, ping :) (I know you were in holidays) S On 07/07/2014 19:17, Sylvestre Ledru wrote: Hello, On 17/06/2014 19:41, Joseph S. Myers wrote: On Tue, 17 Jun 2014, Sylvestre Ledru wrote: OK. I will do that. We should test the following: * default = run just -Wreturn-type * -Wreturn-type = Run both * -Wreturn-type + -Wmissing-return = Run both * -Wno-return-type + -Wmissing-return = Run just the second one * -Wno-return-type + -Wno-missing-return = Run none Do you see any other? That looks like the right things to test, if there are no changes for anything other than those options. Here it is: https://github.com/sylvestre/gcc/commit/db8aaac91aa09fd1ec1cc8974586aec45a221e71 Is that what you expected? Besides that, are you OK with my changes? (with the tests updated) The tests are key to reviewing whether the code changes actually do the right thing. Right. Thanks again for your help and comments, it is really appreciated, Sylvestre
libgo patch committed: Remove unused variable
This patch from Peter Collingbourne removes an unused variable from
libgo. The variable is set but never used, and gccgo was not giving an
error about such cases. I will shortly commit a gccgo patch to detect
this case. This patch bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r cc0233176c9b libgo/go/reflect/value.go
--- a/libgo/go/reflect/value.go Sun Jul 20 08:12:13 2014 -0700
+++ b/libgo/go/reflect/value.go Sun Jul 20 12:19:22 2014 -0700
@@ -434,13 +434,12 @@
// Get function pointer, type.
t := v.typ
var (
- fn unsafe.Pointer
- rcvr Value
- rcvrtype *rtype
+ fn unsafe.Pointer
+ rcvr Value
)
if v.flagflagMethod != 0 {
rcvr = v
- rcvrtype, t, fn = methodReceiver(op, v, int(v.flag)flagMethodShift)
+ _, t, fn = methodReceiver(op, v, int(v.flag)flagMethodShift)
} else if v.flagflagIndir != 0 {
fn = *(*unsafe.Pointer)(v.ptr)
} else {
[PATCH, rs6000, committed] Fix unspec typo
Hi, UNSPEC_VSLDOI was misspelled. It bothered me. I fixed it. Regstrapped on powerpc64le-unknown-linux-gnu, committed as obvious. Thanks, Bill 2014-07-20 Bill Schmidt wschm...@linux.vnet.ibm.com * config/rs6000/altivec.md (unspec enum): Fix typo in UNSPEC_VSLDOI. (altivec_vsldoi_mode): Likewise. Index: gcc/config/rs6000/altivec.md === --- gcc/config/rs6000/altivec.md(revision 212872) +++ gcc/config/rs6000/altivec.md(working copy) @@ -67,7 +67,7 @@ UNSPEC_VCTSXS UNSPEC_VLOGEFP UNSPEC_VEXPTEFP - UNSPEC_VLSDOI + UNSPEC_VSLDOI UNSPEC_VUNPACK_HI_SIGN UNSPEC_VUNPACK_LO_SIGN UNSPEC_VUNPACK_HI_SIGN_DIRECT @@ -2077,7 +2077,7 @@ (unspec:VM [(match_operand:VM 1 register_operand v) (match_operand:VM 2 register_operand v) (match_operand:QI 3 immediate_operand i)] - UNSPEC_VLSDOI))] + UNSPEC_VSLDOI))] TARGET_ALTIVEC vsldoi %0,%1,%2,%3 [(set_attr type vecperm)])
Re: a new libgcov interface: __gcov_dump_all
On 07/18/14 22:41, Xinliang David Li wrote: Hi, the following patch implements a new dumper interface to allow dumping of profile data for all instrumented shared libraries. For good reasons, existing libgcov implements the dumping on a per-shared library basis (i.e., gcov_exit is hidden, gcov_list is file static). This allows each shared library's profile data to be dumped independently with separate summary data. The downside is that there is no interface that can be invoked to dump profile data for all shared modules. This seems like useful functionality, but I don't think this is the right way to do this. You're duplicating the gcov info object chain. Why can't you expose gcov_list from gcov-driver.c (possibly with a different name, of course? nathan
Go patch committed: Error for vars that are set but not used
This patch improves the Go frontend to give an error for any variables
that are set but not used. This matches the behaviour of the gc Go
compiler. This Go language spec does not require this, but it is
permitted as an implementation restriction, and it seems like a good
idea to make the compilers compatible. This required changing one test
in the testsuite; I've sent a patch to the master testsuite with this
change (https://codereview.appspot.com/116050043). Bootstrapped and ran
updated Go testsuite on x86_64-unknown-linux-gnu. Committed to
mainline.
Ian
Index: gcc/go/gofrontend/parse.cc
===
--- gcc/go/gofrontend/parse.cc (revision 212872)
+++ gcc/go/gofrontend/parse.cc (working copy)
@@ -2115,8 +2115,8 @@ Parse::simple_var_decl_or_assignment(con
for (Typed_identifier_list::const_iterator p = til.begin();
p != til.end();
++p)
- exprs-push_back(this-id_to_expression(p-name(),
- p-location()));
+ exprs-push_back(this-id_to_expression(p-name(), p-location(),
+ true));
Expression_list* more_exprs =
this-expression_list(NULL, true, may_be_composite_lit);
@@ -2509,7 +2509,10 @@ Parse::operand(bool may_be_sink, bool* i
}
case Named_object::NAMED_OBJECT_VAR:
case Named_object::NAMED_OBJECT_RESULT_VAR:
- this-mark_var_used(named_object);
+ // Any left-hand-side can be a sink, so if this can not be
+ // a sink, then it must be a use of the variable.
+ if (!may_be_sink)
+ this-mark_var_used(named_object);
return Expression::make_var_reference(named_object, location);
case Named_object::NAMED_OBJECT_SINK:
if (may_be_sink)
@@ -2724,7 +2727,7 @@ Parse::composite_lit(Type* type, int dep
Gogo* gogo = this-gogo_;
val = this-id_to_expression(gogo-pack_hidden_name(identifier,
is_exported),
- location);
+ location, false);
is_name = true;
}
else
@@ -3241,7 +3244,8 @@ Parse::call(Expression* func)
// Return an expression for a single unqualified identifier.
Expression*
-Parse::id_to_expression(const std::string name, Location location)
+Parse::id_to_expression(const std::string name, Location location,
+ bool is_lhs)
{
Named_object* in_function;
Named_object* named_object = this-gogo_-lookup(name, in_function);
@@ -3260,7 +3264,8 @@ Parse::id_to_expression(const std::strin
return Expression::make_const_reference(named_object, location);
case Named_object::NAMED_OBJECT_VAR:
case Named_object::NAMED_OBJECT_RESULT_VAR:
- this-mark_var_used(named_object);
+ if (!is_lhs)
+ this-mark_var_used(named_object);
return Expression::make_var_reference(named_object, location);
case Named_object::NAMED_OBJECT_SINK:
return Expression::make_sink(location);
@@ -5025,7 +5030,7 @@ Parse::send_or_recv_stmt(bool* is_send,
*val = this-id_to_expression(gogo-pack_hidden_name(recv_var,
is_rv_exported),
- recv_var_loc);
+ recv_var_loc, true);
saw_comma = true;
}
else
@@ -5727,6 +5732,13 @@ Parse::verify_not_sink(Expression* expr)
error_at(expr-location(), cannot use _ as value);
expr = Expression::make_error(expr-location());
}
+
+ // If this can not be a sink, and it is a variable, then we are
+ // using the variable, not just assigning to it.
+ Var_expression* ve = expr-var_expression();
+ if (ve != NULL)
+this-mark_var_used(ve-named_object());
+
return expr;
}
Index: gcc/go/gofrontend/parse.h
===
--- gcc/go/gofrontend/parse.h (revision 212872)
+++ gcc/go/gofrontend/parse.h (working copy)
@@ -236,7 +236,7 @@ class Parse
bool* is_type_switch, bool* is_parenthesized);
Type* reassociate_chan_direction(Channel_type*, Location);
Expression* qualified_expr(Expression*, Location);
- Expression* id_to_expression(const std::string, Location);
+ Expression* id_to_expression(const std::string, Location, bool);
void statement(Label*);
bool statement_may_start_here();
void labeled_stmt(const std::string, Location);
Index: gcc/testsuite/go.test/test/shift1.go
===
--- gcc/testsuite/go.test/test/shift1.go (revision 212872)
+++ gcc/testsuite/go.test/test/shift1.go (working copy)
@@ -238,4 +238,6 @@ func _() {
z = (1. s) (1 s)// ERROR non-integer|type complex128
z = (1. s) (1. s) // ERROR non-integer|type complex128
z = (1.1 s) (1.1 s) // ERROR invalid|truncated|complex128
+
+ _, _, _ = x, y, z
}
Re: a new libgcov interface: __gcov_dump_all
The gcov_info chain is not duplicated -- there is already one chain (linking only modules of the library) per shared library in current implementation. My change does not affect underlying behavior at all -- it merely introduces a new interface to access private dumper methods associated with shared libs. David On Sun, Jul 20, 2014 at 12:42 PM, Nathan Sidwell nat...@acm.org wrote: On 07/18/14 22:41, Xinliang David Li wrote: Hi, the following patch implements a new dumper interface to allow dumping of profile data for all instrumented shared libraries. For good reasons, existing libgcov implements the dumping on a per-shared library basis (i.e., gcov_exit is hidden, gcov_list is file static). This allows each shared library's profile data to be dumped independently with separate summary data. The downside is that there is no interface that can be invoked to dump profile data for all shared modules. This seems like useful functionality, but I don't think this is the right way to do this. You're duplicating the gcov info object chain. Why can't you expose gcov_list from gcov-driver.c (possibly with a different name, of course? nathan
Fix ICE on unaligned assignment of return value
This is a regression present on mainline and 4.9 branch and visible e.g. on
SPARC64: the code dealing with values returned in PARALLEL fails to handle the
case of an unaligned target if the mode is an integral mode and not BLKmode.
Tested on SPARC64/Solaris and x86-64/Linux, applied on mainline and 4.9 branch
as obvious.
2014-07-20 Eric Botcazou ebotca...@adacore.com
* expr.c (store_field): Handle VOIDmode for calls that return values
in multiple locations.
2014-07-20 Eric Botcazou ebotca...@adacore.com
* gnat.dg/pack20.ad[sb]: New test.
* gnat.dg/pack20_pkg.ads: New helper.
--
Eric BotcazouIndex: expr.c
===
--- expr.c (revision 212833)
+++ expr.c (working copy)
@@ -6581,7 +6581,7 @@ store_field (rtx target, HOST_WIDE_INT b
{
HOST_WIDE_INT size = int_size_in_bytes (TREE_TYPE (exp));
rtx temp_target;
- if (mode == BLKmode)
+ if (mode == BLKmode || mode == VOIDmode)
mode = smallest_mode_for_size (size * BITS_PER_UNIT, MODE_INT);
temp_target = gen_reg_rtx (mode);
emit_group_store (temp_target, temp, TREE_TYPE (exp), size);package body Pack20 is
procedure Proc (A : Rec) is
Local : Rec := A;
begin
Modify (Local.Fixed);
end;
end Pack20;-- { dg-do compile }
with Pack20_Pkg; use Pack20_Pkg;
package Pack20 is
type Rec is record
Simple_Type : Integer;
Fixed: String_Ptr;
end record;
pragma Pack (Rec);
procedure Proc (A : Rec);
end Pack20;package Pack20_Pkg is
type String_Ptr is access all String;
procedure Modify (Fixed : in out String_Ptr);
end Pack20_Pkg;
Fix RTL load motion bug with -fnon-call-exceptions
We have a testcase that is miscompiled at -O3 by our GCC 4.9-based compiler, although it isn't by the pristine GCC 4.9 compiler. You need a specific combination of events (aggressive inlining, -fnon-call-exceptions, memory accesses marked MEM_NOTRAP_P) which causes RTL load motion to wrongly delete a MEM_NOTRAP_P load because there is another load from the same address but without MEM_NOTRAP_P, the root cause being that simple_mem will return true for the former but false for the latter. Setting MEM_NOTRAP_P is a best effort thing so not setting it should not lead to wrong code. Tested on x86-64/Linux, applied on the mainline. 2014-07-20 Eric Botcazou ebotca...@adacore.com * cse.c (exp_equiv_p) MEM: For GCSE, return 0 for expressions with different trapping status if -fnon-call-exceptions is enabled. -- Eric BotcazouIndex: cse.c === --- cse.c (revision 212833) +++ cse.c (working copy) @@ -2687,6 +2687,13 @@ exp_equiv_p (const_rtx x, const_rtx y, i the same attributes share the same mem_attrs data structure. */ if (MEM_ATTRS (x) != MEM_ATTRS (y)) return 0; + + /* If we are handling exceptions, we cannot consider two expressions + with different trapping status as equivalent, because simple_mem + might accept one and reject the other. */ + if (cfun-can_throw_non_call_exceptions + (MEM_NOTRAP_P (x) != MEM_NOTRAP_P (y))) + return 0; } break;
[PATCH, 4.9/4.10] Profile based option tuning
Hi,
This patch tunes optimization options based on profile data:
* Disable PGO options if profile is not available or empty.
* Optimize for size if profile is available but empty.
Here is an experiment on Firefox PGO build:
CPU Intel Core i7-4770
RAM 32 GB
OSDebian sid amd64
Firefox sourcemozilla-central, changeset 4bafe35cfb65
Compiler GCC 4.9.2 20140721 (prerelease)
Result:
Size of libxul.so | Octane benchmark score
PGO w/o this patch67206232 32440.4 +/- 0.35%
PGO w/ this patch66604312 32765.8 +/- 0.56%
With this patch, the size of PGO-built libxul.so decreases by 0.9% and the
performance improves slightly.
Regards,
Yuan Pengfei
Peking University
gcc/ChangeLog:
* coverage.c (coverage_check): New function.
* coverage.h (coverage_check): New function.
* toplev.c (profile_based_option_override): New function.
(process_options): Add profile based option tuning.
diff --git a/gcc/coverage.c b/gcc/coverage.c
index 4c06fa4..205bee5 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -1128,6 +1128,75 @@ coverage_obj_finish (vecconstructor_elt, va_gc *ctor)
varpool_finalize_decl (gcov_info_var);
}
+/* Check the profile data file.
+ Return -1 if the file is not available or corrupted,
+ 0 if the file is available and all counters are zero,
+ 1 otherwise. */
+
+int
+coverage_check (const char *filename)
+{
+ int ret = 0;
+ int len = strlen (filename);
+ int prefix_len = 0;
+ gcov_unsigned_t tag;
+ char *data_filename;
+
+ if (!profile_data_prefix !IS_ABSOLUTE_PATH (filename))
+profile_data_prefix = getpwd ();
+
+ if (profile_data_prefix)
+prefix_len = strlen (profile_data_prefix);
+
+ data_filename = XNEWVEC (char, len + strlen (GCOV_DATA_SUFFIX)
+ + prefix_len + 2);
+
+ if (profile_data_prefix)
+{
+ memcpy (data_filename, profile_data_prefix, prefix_len);
+ data_filename[prefix_len++] = '/';
+}
+ memcpy (data_filename + prefix_len, filename, len);
+ strcpy (data_filename + prefix_len + len, GCOV_DATA_SUFFIX);
+
+ if (!gcov_open (data_filename, 1))
+return -1;
+ if (!gcov_magic (gcov_read_unsigned (), GCOV_DATA_MAGIC)
+ || gcov_read_unsigned () != GCOV_VERSION)
+{
+ gcov_close ();
+ return -1;
+}
+ gcov_read_unsigned ();
+
+ while ((tag = gcov_read_unsigned ()))
+{
+ gcov_unsigned_t length = gcov_read_unsigned ();
+ gcov_position_t offset = gcov_position ();
+
+ if (GCOV_TAG_IS_COUNTER (tag))
+{
+ unsigned n_counts = GCOV_TAG_COUNTER_NUM (length);
+ unsigned ix;
+
+ for (ix = 0; ix != n_counts; ix++)
+if (gcov_read_counter ())
+ ret = 1;
+}
+ gcov_sync (offset, length);
+
+ if (gcov_is_error ())
+{
+ ret = -1;
+ break;
+}
+}
+
+ gcov_close ();
+
+ return ret;
+}
+
/* Perform file-level initialization. Read in data file, generate name
of notes file. */
diff --git a/gcc/coverage.h b/gcc/coverage.h
index 81f87a6..51d1119 100644
--- a/gcc/coverage.h
+++ b/gcc/coverage.h
@@ -22,6 +22,7 @@ along with GCC; see the file COPYING3. If not see
#include gcov-io.h
+extern int coverage_check (const char *);
extern void coverage_init (const char *);
extern void coverage_finish (void);
diff --git a/gcc/toplev.c b/gcc/toplev.c
index d646faf..b0c3906 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -1222,6 +1222,77 @@ init_alignments (void)
align_functions_log = floor_log2 (align_functions * 2 - 1);
}
+/* Override options based on profile. */
+
+static void
+profile_based_option_override (void)
+{
+ int status;
+ const char *name = aux_base_name;
+
+ if (!flag_branch_probabilities)
+return;
+
+ if (!name)
+{
+ char *newname;
+ if (!main_input_filename)
+return;
+ newname = xstrdup (lbasename (main_input_filename));
+ strip_off_ending (newname, strlen (newname));
+ name = newname;
+}
+
+ status = coverage_check (name);
+ if (status 0)
+return;
+
+ /* Profile data file is valid and all profile counters are zero.
+ Prefer optimizing code size. */
+ if (status == 0)
+{
+ optimize = 2;
+ optimize_size = 1;
+ maybe_set_param_value (PARAM_MIN_CROSSJUMP_INSNS, 1,
+ param_values, global_options_set.x_param_values);
+
+ /* Ignore coverage mismatch since all counters are zero. */
+ diagnostic_classify_diagnostic (global_dc, OPT_Wcoverage_mismatch,
+ DK_IGNORED, UNKNOWN_LOCATION);
+}
+
+ if (!flag_profile_use)
+return;
+
+ /* Disable optimization options for PGO. */
+ if (!global_options_set.x_flag_profile_values)
+flag_profile_values = false;
+ if (!global_options_set.x_flag_unroll_loops)
+flag_unroll_loops = false;
+ if (!global_options_set.x_flag_peel_loops)
+flag_peel_loops = false;
+ if
Re: [PATCH, 4.9/4.10] Profile based option tuning
Sorry, tabs seems converted to spaces automatically. Please use the attachment instead. 2014-07-21 13:13 GMT+08:00 Pengfei Yuan 0xcool...@gmail.com: Hi, This patch tunes optimization options based on profile data: * Disable PGO options if profile is not available or empty. * Optimize for size if profile is available but empty. Here is an experiment on Firefox PGO build: CPU Intel Core i7-4770 RAM 32 GB OSDebian sid amd64 Firefox sourcemozilla-central, changeset 4bafe35cfb65 Compiler GCC 4.9.2 20140721 (prerelease) Result: Size of libxul.so | Octane benchmark score PGO w/o this patch67206232 32440.4 +/- 0.35% PGO w/ this patch66604312 32765.8 +/- 0.56% With this patch, the size of PGO-built libxul.so decreases by 0.9% and the performance improves slightly. Regards, Yuan Pengfei Peking University gcc.patch Description: Binary data
