[Bug c++/66118] New: Compiler segmentation fault when compiling std::function on aix6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66118 Bug ID: 66118 Summary: Compiler segmentation fault when compiling std::function on aix6 Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gabriel.sztejnworcel at yahoo dot com Target Milestone: --- Created attachment 35521 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35521action=edit Source + generated temp files Getting the following error when compiling the attached source file (test.cpp in the zip) on aix6 (the same file compiles with no problems on aix7): g++: internal compiler error: Segmentation fault (program as) libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. The command i used: g++ test.cpp -std=c++11 -save-temps
[Bug target/66115] When using -O0 with -mavx the compiler uses aligned loads for possibly unaligned function parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66115 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- It is the requirement. _mm*_loadu* are a special case, but the C __m128i type itself requires 16-byte alignment. Just print __alignof__ (__m128i)... Just use _mm*_loadu* if the load is from unaligned pointer, and recent versions should when optimizing be able to optimize that case into a memory load in AVX instruction.
[Bug tree-optimization/66117] GCC can not compile when graphite is enabled, due to missing isl headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66117 --- Comment #2 from Paul Beeler pbeeler80 at gmail dot com --- A second shot at a patch: Included HAVE_isl in gcc/graphite-poly.h Other files that include graphite-poly.h will have isl_constraint functions defined. https://github.com/SaberMod/GCC_SaberMod/commit/3494aee764bb64948d6cd2f2c430cfc8e69ba078
[Bug tree-optimization/66117] GCC can not compile when graphite is enabled, due to missing isl headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66117 --- Comment #3 from Paul Beeler pbeeler80 at gmail dot com --- Final patch will work to be the most minimal for changes and HAVE_isl https://github.com/SaberMod/GCC_SaberMod/commit/114e4e9470260a839d55aad2421fb646af12697b
[Bug fortran/66041] [6 Regression] Matmul ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66041 --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org --- Author: tkoenig Date: Tue May 12 06:37:43 2015 New Revision: 223031 URL: https://gcc.gnu.org/viewcvs?rev=223031root=gccview=rev Log: 2015-05-12 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/66041 PR fortran/37131 * gfortran.h (gfc_array_spec): Add field resolved. * array.c (gfc_resolve_array_spec): Resolve array spec only once. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/gfortran.h
[Bug fortran/37131] inline matmul for small matrix sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131 --- Comment #30 from Thomas Koenig tkoenig at gcc dot gnu.org --- Author: tkoenig Date: Tue May 12 06:37:43 2015 New Revision: 223031 URL: https://gcc.gnu.org/viewcvs?rev=223031root=gccview=rev Log: 2015-05-12 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/66041 PR fortran/37131 * gfortran.h (gfc_array_spec): Add field resolved. * array.c (gfc_resolve_array_spec): Resolve array spec only once. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/gfortran.h
[Bug sanitizer/64839] libsanitizer shouldn't require rpc/xdr.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64839 --- Comment #13 from ygribov at gcc dot gnu.org --- Author: ygribov Date: Tue May 12 07:02:09 2015 New Revision: 223032 URL: https://gcc.gnu.org/viewcvs?rev=223032root=gccview=rev Log: 2015-05-12 Yury Gribov y.gri...@samsung.com Backport from mainline 2015-04-13 Yury Gribov y.gri...@samsung.com PR sanitizer/64839 * sanitizer_common/sanitizer_platform.h: Cherry pick upstream r234470. * sanitizer_common/sanitizer_platform_limits_posix.cc: Ditto. * configure.ac (RPC_DEFS): Check for precense of RPC headers. * sanitizer_common/Makefile.am (DEFS): Pass info to compiler. * Makefile.in: Regenerate. * asan/Makefile.in: Regenerate. * config.h.in: Regenerate. * configure: Regenerate. * interception/Makefile.in: Regenerate. * libbacktrace/Makefile.in: Regenerate. * lsan/Makefile.in: Regenerate. * sanitizer_common/Makefile.in: Regenerate. * tsan/Makefile.in: Regenerate. * ubsan/Makefile.in: Regenerate. Modified: branches/gcc-5-branch/libsanitizer/ChangeLog branches/gcc-5-branch/libsanitizer/Makefile.in branches/gcc-5-branch/libsanitizer/asan/Makefile.in branches/gcc-5-branch/libsanitizer/config.h.in branches/gcc-5-branch/libsanitizer/configure branches/gcc-5-branch/libsanitizer/configure.ac branches/gcc-5-branch/libsanitizer/interception/Makefile.in branches/gcc-5-branch/libsanitizer/libbacktrace/Makefile.in branches/gcc-5-branch/libsanitizer/lsan/Makefile.in branches/gcc-5-branch/libsanitizer/sanitizer_common/Makefile.am branches/gcc-5-branch/libsanitizer/sanitizer_common/Makefile.in branches/gcc-5-branch/libsanitizer/sanitizer_common/sanitizer_platform.h branches/gcc-5-branch/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc branches/gcc-5-branch/libsanitizer/tsan/Makefile.in branches/gcc-5-branch/libsanitizer/ubsan/Makefile.in
[Bug c++/59224] [4.7/4.8/4.9 Regression] std::uncaught_exception returns true while constructing exception.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59224
li xin lixin.fnst at cn dot fujitsu.com changed:
What|Removed |Added
CC||lixin.fnst at cn dot
fujitsu.com
--- Comment #8 from li xin lixin.fnst at cn dot fujitsu.com ---
(In reply to Jason Merrill from comment #5)
Fixed for 4.8.3/4.9. Not fixing on 4.7 branch.
It will lead to the lsb test caes
/libstdcxx-t2c/tests/LanguageSupport/LanguageSupport FAIL.
So I want to know the right return value of std::uncaught_exception() (inside
exception-constructor).
The LSB test code is as follows:
cat main.cpp
#include string.h
#include iostream
using namespace std;
class exception_test : public exception
{
public:
bool result;
exception_test(): exception(){result = uncaught_exception();}
~exception_test() throw(){};
};
int main(int argc, char ** argv)
{
bool result;
try
{
throw exception_test();
}
catch(exception_test et)
{
result = et.result;
}
cerr result endl;
return 0;
}
# g++ ./main.cpp
# ./a.out
0
My GCC version is 4.9.2, the return value of result is 0,and the test is FAIL.
If the the return value of result is 1,and the test will be PASS.
[Bug fortran/66113] Variable n cannot appear in the expression with nested blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66113 --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org --- The reason is that I want to make creation of temporary variables for arrays more sane. Currently, temporary arrays are handled using an allocatable array variable. This obviously does not work if -fno-realloc-lhs is specified, and introduces unneeded complexity in the generated code, which is hard for the middle-end optimizers to remove. What I want to do is, if I want to create a temporary variable for an array, is to change real, dimension(something,other) :: a a(f(x),1:3) into block freeze = f(x) size_1 = 1; size_2 = 3; block real, dimension(size_1, size_2) :: a_tmp a_tmp(:,;) = a(freeze, 1:3) ... end block end block While this might work in the most simple cases, I don't want to introduce instability by hitting a bug with too many nesting levels.
[Bug target/66049] Few AArch64 extend and add with shift tests generates sub optimal code with trunk gcc 6.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66049 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target||aarch64* Status|UNCONFIRMED |NEW Keywords||missed-optimization Last reconfirmed||2015-05-12 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |6.0 Known to fail||6.0 --- Comment #3 from ktkachov at gcc dot gnu.org --- Venkat, are you planning to submit this patch to gcc-patches? Also, does this mean we can remove the patterns that do arith+shift using MULT rtxes? (like *adds_optabmode_multp2)
[Bug target/66112] __builtin_mul_overflow for int16_t emits poor code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66112 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 35522 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35522action=edit gcc5-pr66112.patch Supposedly just using SWI248 instead of SWI48 iterator should fix this, though not sure about all the AMD scheduling stuff.
[Bug target/66112] __builtin_mul_overflow for int16_t emits poor code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66112 --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Jakub Jelinek from comment #1) Created attachment 35522 [details] gcc5-pr66112.patch Supposedly just using SWI248 instead of SWI48 iterator should fix this, though not sure about all the AMD scheduling stuff. Just copy HImode patterns, as is already case with QI, SI/DImode (and we tolerated it). We can macroize these patterns latter, if needed at all. I wonder, why HImode patterns were left out in the first place ...
[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66066 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #11 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Marek Polacek from comment #10) Working on this, but it isn't a simple matter of adding pedantic. Joseph, would testing global_dc-pedantic_errors be an acceptable work-around (with a big ??? note) while a better solution is found?
[Bug middle-end/66127] Division by zero gets folded away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66127 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com --- Ideally the front-end folding of expressions-of-constants might avoid folding-for-optimization such as this (instead just folding cases where the evaluated operands are actually constants, so not folding anything where 1 / 0 is an evaluated operand).
[Bug fortran/66128] New: ICE for some intrinsics with zero sized array parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66128 Bug ID: 66128 Summary: ICE for some intrinsics with zero sized array parameter Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This simplified code snippet with a zero sized array parameter z ... program p integer, parameter :: z(0) = 0 print *, any(z 0) print *, all(z 0) end or this variation ... program p integer, parameter :: z(1:0) = 0 print *, any(z 0) print *, all(z 0) end prints (with gfortran 5.1.1 on SUSE Linux 13.2, 64 bit) internal compiler error: in gfc_conv_intrinsic_anyall, at fortran/trans-intrinsic.c:3149 Whereas, without declaring z as a parameter it works, e.g. program p integer :: z(0) = 0 print *, any(z 0) print *, all(z 0) end Kind regards.
[Bug tree-optimization/66129] New: [6 Regression] FAIL: gcc.dg/vect/vect-strided-*c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66129
Bug ID: 66129
Summary: [6 Regression] FAIL: gcc.dg/vect/vect-strided-*c
execution test
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: rguenther at suse dot de
Target Milestone: ---
On x86, r223059 caused:
FAIL: gcc.dg/vect/vect-strided-a-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-a-mult.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-strided-a-u16-i2.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u16-i2.c -flto -ffat-lto-objects execution
test
FAIL: gcc.dg/vect/vect-strided-a-u16-i4.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u16-i4.c -flto -ffat-lto-objects execution
test
FAIL: gcc.dg/vect/vect-strided-a-u16-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u16-mult.c -flto -ffat-lto-objects execution
test
FAIL: gcc.dg/vect/vect-strided-a-u32-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u32-mult.c -flto -ffat-lto-objects execution
test
FAIL: gcc.dg/vect/vect-strided-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-mult.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-strided-mult-char-ls.c execution test
FAIL: gcc.dg/vect/vect-strided-mult-char-ls.c -flto -ffat-lto-objects execution
test
FAIL: gcc.dg/vect/vect-strided-u16-i2.c execution test
FAIL: gcc.dg/vect/vect-strided-u16-i2.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-strided-u16-i4.c execution test
FAIL: gcc.dg/vect/vect-strided-u16-i4.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-strided-u32-i4.c execution test
FAIL: gcc.dg/vect/vect-strided-u32-i4.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-strided-u32-i8.c execution test
FAIL: gcc.dg/vect/vect-strided-u32-i8.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-strided-u32-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-u32-mult.c -flto -ffat-lto-objects execution
test
FAIL: gcc.dg/vect/vect-strided-u8-i2.c execution test
FAIL: gcc.dg/vect/vect-strided-u8-i2.c -flto -ffat-lto-objects execution test
with
make check-gcc RUNTESTFLAGS=vect.exp=vect-strided*.c
--target_board='unix{-march=corei7}'
[Bug c++/66130] New: invalid use of non-static member function message could be clearer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66130 Bug ID: 66130 Summary: invalid use of non-static member function message could be clearer Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Target Milestone: --- Today g++ gave me invalid use of non-static member function. However, from the context it was unclear exactly which thing on the line was the invalid use. (Mostly due to bug 61940 giving an imprecise location). I think this warning would be more useful if it mentioned the name of the member function in question. In my case this would have made the problem immediately clear.
[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66066 --- Comment #13 from Marek Polacek mpolacek at gcc dot gnu.org --- I expect to have a proper fix (additional folding in c_fully_fold_internal) today or tomorrow, depends on how many issues I hit along the way (see e.g. PR66127). The tzdata issue seems to be being worked on, so I think the pedantic stopgap isn't needed right now.
[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66066 --- Comment #12 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Tue, 12 May 2015, manu at gcc dot gnu.org wrote: Working on this, but it isn't a simple matter of adding pedantic. Joseph, would testing global_dc-pedantic_errors be an acceptable work-around (with a big ??? note) while a better solution is found? If you want a workaround, a test for pedantic would be the natural workaround, but I think the proper fix is folding as I described at https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01015.html to allow these cases to reach the existing pedwarn-if-pedantic logic.
[Bug fortran/66128] ICE for some intrinsics with zero sized array parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66128 --- Comment #1 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Some more examples with other error messages. This one ... program p integer, parameter :: z(0) = 0 print *, count(z 0) end yields : internal compiler error: in gfc_conv_intrinsic_count, at fortran/trans-intrinsic.c:3233 This one ... program p integer, parameter :: z(0) = 0 print *, iall(z, z 0) print *, iany(z, z 0) print *, iparity(z, z 0) print *, parity(z 0) print *, product(z, z 0) print *, sum(z, z 0) end yields : internal compiler error: in gfc_conv_intrinsic_arith, at fortran/trans-intrinsic.c:3357 This one ... program p integer, parameter :: z(0) = 0 print *, minval(z, z 0) print *, maxval(z, z 0) end yields : internal compiler error: in gfc_conv_intrinsic_minmaxval, at fortran/trans-intrinsic.c:4253
[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66066 --- Comment #14 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Marek Polacek from comment #13) I expect to have a proper fix (additional folding in c_fully_fold_internal) today or tomorrow, depends on how many issues I hit along the way (see e.g. PR66127). The tzdata issue seems to be being worked on, so I think the pedantic stopgap isn't needed right now. OK, great. That seems a step in the right direction. Thanks for fixing this!
[Bug middle-end/66127] Division by zero gets folded away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66127 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- I suppose this particular issue might be even relevant to e.g. -mcheck-zero-division on MIPS, i.e. everywhere where we're expect to trap on integer division by zero. (ubsan's -fsanitize=integer-divide-by-zero isn't affected by this, because we add the instrumentation very early, before the division is lost. Otherwise we'd miss a diagnostic.)
[Bug middle-end/66127] Division by zero gets folded away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66127 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to jos...@codesourcery.com from comment #1) Ideally the front-end folding of expressions-of-constants might avoid folding-for-optimization such as this (instead just folding cases where the evaluated operands are actually constants, so not folding anything where 1 / 0 is an evaluated operand). I understand that Marek is saying that currently: 1 / 0 is not folded, but 0 * (1 / 0) is folded into 0. The answer is that we really need to separate the FE folding from the ME one, and do only FE folding for language conformance purposes, while we can do ME folding for warnings and when the FE is finished. Isn't this what you explain in text quoted at A.5 at https://gcc.gnu.org/wiki/Better_Diagnostics? This will also liberate the ME to do optimizations that before could not do because we wanted to reject invalid programs with -pedantic-errors. I seem to remember there has been further discussion about this after or while match.pd was implemented, discussing whether it was worth it that the FE saves the GIMPLE generated when doing FE folding (or ME folding in case of FE warnings requesting it), but I cannot find a link now.
[Bug c/66090] Wrong loop code generation with -O2 on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66090 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED CC||rguenth at gcc dot gnu.org Resolution|INVALID |--- --- Comment #3 from Richard Earnshaw rearnsha at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #2) Since the pointer is wrapping to null, you need to use -fno-delete-null-pointer-checks to disable removing of checks of null pointers or rather it enables allowing pointers to wrap to become null. In C, once a pointer is non-null, it can't become null by adding a value to it. So GCC enables an optimization around that case (and fno-delete-null-pointer-checks disables that optimization). So no GCC bug, just wrongly assuming pointers can't become null pointers if they were not null pointers. I'm inclined to disagree. Firstly, the code does not check for a null pointer, it checks a loop iterator variable. Secondly, although the pointer value wraps to zero, that value is never dereferenced; the last memory access is at 0xfffc. So I think the compiler is incorrectly removing a valid termination check. Richi, I'd like your opinion on this one.
[Bug ipa/65908] [5/6 Regression] ICE: in expand_thunk, at cgraphunit.c:1700
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65908 --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org --- I think pushing TYPE_CANONICAL is a bug: we do check ODR properties of the parameter and TYPE_CANONICAL is not guaranteed to be the same. Just remove the TYPE_CANONICAL wrap here. The patch seems OK with this change both for mainline and branch. We will match the types of DECL_ARGUMENTS when verifying the body here: for (arg1 = DECL_ARGUMENTS (decl), arg2 = DECL_ARGUMENTS (m_compared_func-decl); arg1; arg1 = DECL_CHAIN (arg1), arg2 = DECL_CHAIN (arg2)) if (!m_checker-compare_decl (arg1, arg2)) return return_false (); However I think there is one extra case to deal with. For functions that are !prototype_p, we get empty ARG_TYPES and only have ARGUMENTS. Such functions will bypass the checks: if (POINTER_TYPE_P (arg_types[i]) (TYPE_RESTRICT (arg_types[i]) != TYPE_RESTRICT (m_compared_func-arg_types[i]))) return return_false_with_msg (argument restrict flag mismatch); /* nonnull_arg_p implies non-zero range to REFERENCE types. */ if (POINTER_TYPE_P (arg_types[i]) TREE_CODE (arg_types[i]) != TREE_CODE (m_compared_func-arg_types[i]) opt_for_fn (decl, flag_delete_null_pointer_checks)) return return_false_with_msg (pointer wrt reference mismatch); Please factor out this code to a function compatible_parm_types_p and call it both from sem_function::equals_wpa and the loop above. Honza
[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66066 --- Comment #15 from Marek Polacek mpolacek at gcc dot gnu.org --- Created attachment 35534 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35534action=edit gcc6-pr66066 Untested patch without a test
[Bug inline-asm/65897] GAS(asm) named variable of extended asm (type ::m or g) generated in wrong code style, variable stays still in .att_syntax -32(%ebp) not .intel_syntax noprefix DWORD P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65897
stanley sstsoft at wp dot pl changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #2 from stanley sstsoft at wp dot pl ---
#include iostream
using namespace std;
int i asm(i);
int main() {
i = 0;
cout !!!Hello World!!! endl; // prints !!!Hello World!!!
cout i= i endl;
asm(.intel_syntax noprefix\n mov eax,13\n mov [i],eax\n);
cout i= i endl;
i = 0;
cout i= i endl;
asm(.intel_syntax noprefix\n mov eax,14\n mov %[named_var],eax\n :
[named_var] =g (i));
cout i= i endl;
return 0;
}
Gives output like this:
!!!Hello World!!!
i=0
i=13
i=0
i=14
1. I have checked LLVM/Clang + Eclipse CDC.
It can do this ^^ trick without a single problem(.att_syntax switched globally
but it compiles as a charm) It's only possible with Clang(compatible with GAS),
and I don't even need to end asm() block switched to correct .att_syntax.
With GCC compiler if I don't do this, the linker would be confused for first
line of code after my asm(.intel) block (wrong syntax of gcc product). As
You mentioned GCC is blind to local switches into asm block. Why? Because it's
his nature ofc :)
2. Simple mov i,eax wouldn't work with gcc/gas, neither mov [i],eax, mov
DWORD PTR[i],eax because gcc ignores [] and it doesn't matter in the output.
This is different than written in manual - for me it's a bug. But..
since I know i it's address located in ds:blabla and gcc delete all of [] if
I want to access i I should mov edi,i then mov [edi],eax or something
like that. Again..GCC is not buggy? Huh? :)
For references or pointers it's the same so it's very confusing. GAS doesn't
recognizes *. The only way to force is named variable but as I mentioned
in previous comment - it doesn't working properly.
3. Indexes also not working[1] properly for pointers. If i pass:
char bla[10]; //and then
char *bla_ptr = (char*)bla; //and then, into asm mov bla_ptr[2],al it
wouldn't copy al into 3rd byte of bla?! but into 3rd hihgest byte(little
indian) of bla_ptr val. After that it wouldnt be correct pointer anymore
(pointing somewhere but not there). It could be very confuseing. Rather than
everytime copy variables into some register and then [edi],eax global named
variables would be the best way.. but not working correctly in .intel_syntax
4. The only way to do write into i without named variables in extended asm
inline is copy it's adress into register eq. mov edi,i; then mov [edi],somedata
When i switch -masm=intel it could be okey but... what if i want to compile
someone else code + my code in same project? But with different syntaxes?
Those guys know's how GCC works so they wrote .att_syntax or end their asm's.
Then.. linker is confused again but now with intel syntaxed gcc output rather
than .att :)
But, Andrew said - it's not a bug, it's a? Feature?
I know global variables are bad, very bad especially in multi-threaded program,
i know why ;) I know the __bulitin, i know .s offline assembly. I know it
would be easier to access and manipulate some local i by simple define it as
int i asm(eax); or : =r (i) : eax) and just manipulate them without
wasteing processor time(accessing memmory) and wasteing stack space for
storeing it. But hey... instead of helping GCC compicates it :)
For ATT syntax everything(almost) works as it should but hey.. why bother
people for intel if it's not working correctly!
END. Clang follows local asm() switches and gives correct .s output for it's
own compiled C code after them. It now suport for Microsoft asm{} - smart
enought to discover what registers dev use. Smart enought to move data into
memory adress not complain. Linker is not confused when i compile units from
other developers whose wrote them for GCC without -masm=intel so end's up with
.att_syntax by default. They could end up whatever they like. I could do
whatever i like - what should be as much intuitive as it could in SSE,AVX era
when good C code is not enought.
In GCC this is very serious problem, gcc stuck in 70's .ATT era
If gas have no way it shouldn't support for g m type variables then! Or
someone should make them see each other. Lack of GAS - GCC communication
whatever... this is not in my worries list, but on gcc commiters. Maybe someone
should open way for it!?
huh? Andrew?
[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #57 from Andrew Macleod amacleod at redhat dot com ---
Author: amacleod
Date: Tue May 12 20:01:47 2015
New Revision: 223096
URL: https://gcc.gnu.org/viewcvs?rev=223096root=gccview=rev
Log:
2015-05-12 Andrew MacLeod amacl...@redhat.com
PR target/65697
* coretypes.h (MEMMODEL_SYNC, MEMMODEL_BASE_MASK): New macros.
(enum memmodel): Add SYNC_{ACQUIRE,RELEASE,SEQ_CST}.
* tree.h (memmodel_from_int, memmodel_base, is_mm_relaxed,
is_mm_consume,is_mm_acquire, is_mm_release, is_mm_acq_rel,
is_mm_seq_cst, is_mm_sync): New accessor functions.
* builtins.c (expand_builtin_sync_operation,
expand_builtin_compare_and_swap): Use MEMMODEL_SYNC_SEQ_CST.
(expand_builtin_sync_lock_release): Use MEMMODEL_SYNC_RELEASE.
(get_memmodel, expand_builtin_atomic_compare_exchange,
expand_builtin_atomic_load, expand_builtin_atomic_store,
expand_builtin_atomic_clear): Use new accessor routines.
(expand_builtin_sync_synchronize): Use MEMMODEL_SYNC_SEQ_CST.
* optabs.c (expand_compare_and_swap_loop): Use MEMMODEL_SYNC_SEQ_CST.
(maybe_emit_sync_lock_test_and_set): Use new accessors and
MEMMODEL_SYNC_ACQUIRE.
(expand_sync_lock_test_and_set): Use MEMMODEL_SYNC_ACQUIRE.
(expand_mem_thread_fence, expand_mem_signal_fence, expand_atomic_load,
expand_atomic_store): Use new accessors.
* emit-rtl.c (need_atomic_barrier_p): Add additional enum cases.
* tsan.c (instrument_builtin_call): Update check for memory model
beyond
final enum to use MEMMODEL_LAST.
* c-family/c-common.c: Use new accessor for memmodel_base.
* config/aarch64/aarch64.c (aarch64_expand_compare_and_swap): Use new
accessors.
* config/aarch64/atomics.md (atomic_loadmode,atomic_storemode,
arch64_load_exclusivemode, aarch64_store_exclusivemode,
mem_thread_fence, *dmb): Likewise.
* config/alpha/alpha.c (alpha_split_compare_and_swap,
alpha_split_compare_and_swap_12): Likewise.
* config/arm/arm.c (arm_expand_compare_and_swap,
arm_split_compare_and_swap, arm_split_atomic_op): Likewise.
* config/arm/sync.md (atomic_loadmode, atomic_storemode,
atomic_loaddi): Likewise.
* config/i386/i386.c (ix86_destroy_cost_data, ix86_memmodel_check):
Likewise.
* config/i386/sync.md (mem_thread_fence, atomic_storemode): Likewise.
* config/ia64/ia64.c (ia64_expand_atomic_op): Add new memmodel cases
and
use new accessors.
* config/ia64/sync.md (mem_thread_fence, atomic_loadmode,
atomic_storemode, atomic_compare_and_swapmode,
atomic_exchangemode): Use new accessors.
* config/mips/mips.c (mips_process_sync_loop): Likewise.
* config/pa/pa.md (atomic_loaddi, atomic_storedi): Likewise.
* config/rs6000/rs6000.c (rs6000_pre_atomic_barrier,
rs6000_post_atomic_barrier): Add new cases.
(rs6000_expand_atomic_compare_and_swap): Use new accessors.
* config/rs6000/sync.md (mem_thread_fence): Add new cases.
(atomic_loadmode): Add new cases and use new accessors.
(store_quadpti): Add new cases.
* config/s390/s390.md (mem_thread_fence, atomic_storemode): Use new
accessors.
* config/sparc/sparc.c (sparc_emit_membar_for_model): Use new
accessors.
* doc/extend.texi: Update docs to indicate 16 bits are used for memory
model, not 8.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/c-family/c-common.c
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/config/aarch64/atomics.md
trunk/gcc/config/alpha/alpha.c
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/sync.md
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/sync.md
trunk/gcc/config/ia64/ia64.c
trunk/gcc/config/ia64/sync.md
trunk/gcc/config/mips/mips.c
trunk/gcc/config/pa/pa.md
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/sync.md
trunk/gcc/config/s390/s390.md
trunk/gcc/config/sparc/sparc.c
trunk/gcc/coretypes.h
trunk/gcc/doc/extend.texi
trunk/gcc/emit-rtl.c
trunk/gcc/optabs.c
trunk/gcc/tree.h
trunk/gcc/tsan.c
[Bug c++/66130] invalid use of non-static member function message could be clearer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66130 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Keywords||easyhack Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-12 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 --- Confirmed. A small testcase would help. Perhaps it would be even clearer if it said something like: non-static member function can be used only as the operand for the function call operator()
[Bug other/55375] libsanitizer license incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55375 Eliot dsl at dsl dot pp.ua changed: What|Removed |Added CC||dsl at dsl dot pp.ua --- Comment #5 from Eliot dsl at dsl dot pp.ua --- Created attachment 35535 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35535action=edit http://legup.eecg.utoronto.ca http://legup.eecg.utoronto.ca
[Bug fortran/66111] [6 regression] ICE with matmul and vector subscripts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66111 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org --- Fixed, closing.
[Bug fortran/66111] [6 regression] ICE with matmul and vector subscripts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66111 --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org --- Author: tkoenig Date: Tue May 12 21:12:55 2015 New Revision: 223099 URL: https://gcc.gnu.org/viewcvs?rev=223099root=gccview=rev Log: 2015-05-12 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/66111 * frontend-passes.c (has_dimen_vector_ref): New function. (inline_matmul_assign): Use it to return early in case of unhandled vector subscripts. 2015-05-12 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/66111 * gfortran.dg/inline_matmul_10.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/inline_matmul_10.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog
[Bug c++/66091] [c++-concepts] Overloading of member operators based on constraints rejected; regression from r211591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66091 Tom Honermann tom at honermann dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tom Honermann tom at honermann dot net --- Thanks! Confirmed fixed in r223061.
[Bug debug/54114] VTA compile-time performance could be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54114 Eliot dsl at dsl dot pp.ua changed: What|Removed |Added CC||dsl at dsl dot pp.ua --- Comment #14 from Eliot dsl at dsl dot pp.ua --- Comment on attachment 27894 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=27894 XPatch.cpp preprocessed source from xalanc http://legup.eecg.utoronto.ca
[Bug rtl-optimization/65862] [MIPS] IRA/LRA issue: integers spilled to floating-point registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862 --- Comment #11 from Vladimir Makarov vmakarov at gcc dot gnu.org --- (In reply to Robert Suchanek from comment #10) Hi Vlad, I'm pleased with the results so far. In the larger codebase, it behaves as the original patch reverted and I haven't seen a missed case. The code size doesn't seem to be hurt either. I see ~0.5% improvement on average case which is good. Thanks a lot for the patch. I've thrown it against standard regression and it will take some time to complete but I'm confident it will pass. Initially it failed because of a missing declaration of the new_class variable though. Thanks, Robert. If it is ok, I will commit it into the trunk this week. I am going to commit it without the mips hook. So I hope mips maintainers will add the hook by themselves.
[Bug c++/53553] misleading locations for error in initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53553 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||tromey at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Tom Tromey tromey at gcc dot gnu.org --- Dup; preferring the other bug since it is assigned. *** This bug has been marked as a duplicate of bug 61940 ***
[Bug c++/61940] Wrong error location for error in initialization list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61940 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added CC||akim.demaille at gmail dot com --- Comment #3 from Tom Tromey tromey at gcc dot gnu.org --- *** Bug 53553 has been marked as a duplicate of this bug. ***
[Bug c++/61940] Wrong error location for error in initialization list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61940 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added CC||jan.kratochvil at redhat dot com --- Comment #4 from Tom Tromey tromey at gcc dot gnu.org --- *** Bug 59621 has been marked as a duplicate of this bug. ***
[Bug c++/59621] wrong caret / lineno for wrong ctor field initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59621 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||tromey at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from Tom Tromey tromey at gcc dot gnu.org --- Dup; preferring the other bug since it is assigned. *** This bug has been marked as a duplicate of bug 61940 ***
[Bug ipa/65873] [5/6 Regression] Failure to inline always_inline memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65873 --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org --- Patch posted https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01167.html
[Bug ipa/65873] [5/6 Regression] Failure to inline always_inline memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65873 --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Wed May 13 02:54:50 2015 New Revision: 223107 URL: https://gcc.gnu.org/viewcvs?rev=223107root=gccview=rev Log: PR ipa/65873 * ipa-inline.c (can_inline_edge_p): Allow early inlining of always inlines across optimization boundary. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c
[Bug target/66049] Few AArch64 extend and add with shift tests generates sub optimal code with trunk gcc 6.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66049 --- Comment #4 from vekumar at gcc dot gnu.org --- (In reply to ktkachov from comment #3) Venkat, are you planning to submit this patch to gcc-patches? Also, does this mean we can remove the patterns that do arith+shift using MULT rtxes? (like *adds_optabmode_multp2) Hi Kyrill, Yes I am planing to submit the patch. But before that I need to test by putting some assert and check if *adds_optabmode_multp2 and similar patterns are not used anymore.
[Bug tree-optimization/65961] [6 Regression] ice in vect_is_simple_use_1 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65961 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Hmpf, so we have an operand that is both part of a regular SLP node _and_ is part of a SLP node that gets its operand built up from scalars. So obviously looking at STMT_VINFO_VECTORIZABLE (def-of-op) isn't giving the correct answer (it depends on context). I tried to avoid passing down the SLP node to vect_is_simple_use[_1], but that is what it would take to fix this (well, or reject the SLP build while we compute STMT_VINFO_VECTORIZABLE ()). I have to think more about what refactoring would make sense here.
[Bug target/66112] __builtin_mul_overflow for int16_t emits poor code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66112 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #35522|0 |1 is obsolete|| Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-05-12 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 35523 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35523action=edit gcc6-pr66112-1.patch Generic fix, to improve minimum precision computation for unsigned values.
[Bug tree-optimization/66119] [5/6 Regression] in optimization of avx-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66119 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Ah, it's parameter b assigned to local decl b.
[Bug sanitizer/64839] libsanitizer shouldn't require rpc/xdr.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64839 Geoff Nixon geoff at geoff dot codes changed: What|Removed |Added CC||geoff at geoff dot codes --- Comment #16 from Geoff Nixon geoff at geoff dot codes --- Sorry to be an idiot, but I just ran into this building from the 5.1 release tarball. Is the patch attached to this bug (dated 2015-04-10) what I should use to patch against the release? Or is there a different set of changes specific to the 5.1 branch backport?
[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66066 Rohit rohitarulraj at gmail dot com changed: What|Removed |Added CC||rohitarulraj at gmail dot com --- Comment #7 from Rohit rohitarulraj at gmail dot com --- glibc build for PowerPC fails too.
[Bug tree-optimization/66010] [6 Regression] Missed optimization after inlining va_list parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66010 --- Comment #8 from vries at gcc dot gnu.org --- Author: vries Date: Tue May 12 09:46:47 2015 New Revision: 223054 URL: https://gcc.gnu.org/viewcvs?rev=223054root=gccview=rev Log: Don't take address of ap unless necessary 2015-05-12 Tom de Vries t...@codesourcery.com PR tree-optimization/66010 * gimplify.c (gimplify_modify_expr): Handle new do_deref argument of ifn_va_arg. * gimplify.h (gimplify_va_arg_internal): Remove loc parameter. (gimplify_va_arg_internal): Remove loc parameter. Assert no array-typed va_lists are passed, and remove corresponding handling. (gimplify_va_arg_expr): Only take address of ap if necessary. Add do_deref argument to ifn_va_arg. * tree-stdarg.c (expand_ifn_va_arg_1): Handle new do_deref argument of ifn_va_arg. * c-common.c (build_va_arg): Don't mark ap addressable unless necessary. * gcc.dg/tree-ssa/stdarg-2.c: Undo scan xfails for f15. Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/gimplify.c trunk/gcc/gimplify.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/stdarg-2.c trunk/gcc/tree-stdarg.c
[Bug target/66120] New: __builtin_add/sub_overflow for int32_t emit poor code on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66120
Bug ID: 66120
Summary: __builtin_add/sub_overflow for int32_t emit poor code
on ARM
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc.hall at gmail dot com
Target Milestone: ---
Please see related PR66112 for x86
---
#include stdio.h
#include inttypes.h
int
main( int argc, const char *argv[] )
{
int32_t result, a = (int32_t)atoi(argv[1]), b = (int32_t)atoi( argv[2] );
if( __builtin_add_overflow( a, b, result ) )
printf( Overflow\n);
else
printf( Sum is %d\n, result );
}
--
Few instructions on ARM set the overflow flag. Two that do are 32-bit add and
subtract. For these two, GCC could just emit adds or subs followed by
bvs.
Instead (from the last atoi() down) it produces:-
bl atoi@
add r1, r4, r0 @ tmp121, a, b
cmp r0, #0 @ b,
blt .L4 @,
cmp r1, r4 @ tmp121, a
bge .L5 @,
b .L3 @
.L4:
cmp r1, r4 @ tmp121, a
ble .L5 @,
[Bug tree-optimization/66119] [5/6 Regression] in optimization of avx-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66119 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- DEFPARAM (PARAM_SRA_MAX_SCALARIZATION_SIZE_SPEED, sra-max-scalarization-size-Ospeed, Maximum size, in storage units, storage units! But the value seems to be in bits? It gets used as if (tree_to_uhwi (TYPE_SIZE (TREE_TYPE (var))) = max_scalarization_size) max_scalarization_size is 384, the aggregate size is 512. Looks like get_move_ratio returns different things at SRA time (if I re-call it) and the time it gets invoked in toplev.c.
[Bug sanitizer/64839] libsanitizer shouldn't require rpc/xdr.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64839 --- Comment #15 from Yury Gribov y.gribov at samsung dot com --- (In reply to Thierry Reding from comment #14) Thanks Yury. Np, you are welcome. @Harald: could you close the bug if it works for you?
[Bug sanitizer/64839] libsanitizer shouldn't require rpc/xdr.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64839 --- Comment #17 from Yury Gribov y.gribov at samsung dot com --- (In reply to Geoff Nixon from comment #16) what I should use to patch against the release? Or is there a different set of changes specific to the 5.1 branch backport? For 5.1 you'd better use the patch in gcc-5-branch: https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=223032
[Bug tree-optimization/66010] [6 Regression] Missed optimization after inlining va_list parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66010 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from vries at gcc dot gnu.org --- Patch committed, marking resolved fixed.
[Bug tree-optimization/66119] [5/6 Regression] in optimization of avx-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66119 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Fixed by Index: toplev.c === --- toplev.c(revision 223044) +++ toplev.c(working copy) @@ -1311,6 +1311,9 @@ process_options (void) so we can correctly initialize debug output. */ no_backend = lang_hooks.post_options (main_input_filename); + /* Some machines may reject certain combinations of options. */ + targetm.target_option.override (); + /* Set default values for parameters relation to the Scalar Reduction of Aggregates passes (SRA and IP-SRA). We must do this here, rather than in opts.c:default_options_optimization as historically these @@ -1325,9 +1328,6 @@ process_options (void) get_move_ratio (false) * UNITS_PER_WORD, global_options.x_param_values, global_options_set.x_param_values); - /* Some machines may reject certain combinations of options. */ - targetm.target_option.override (); - /* Avoid any informative notes in the second run of -fcompare-debug. */ if (flag_compare_debug) diagnostic_inhibit_notes (global_dc); though not sure whether a 2nd maybe_set_param_value will still allow the target to adjust this default...
[Bug c++/66121] New: internal compiler error: in strip_typedefs, at cp/tree.c:1369
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66121
Bug ID: 66121
Summary: internal compiler error: in strip_typedefs, at
cp/tree.c:1369
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dennis.demidov at gmail dot com
Target Milestone: ---
Created attachment 35527
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35527action=edit
The preprocessed code stripped with the delta tool.
The following code (reduced from [vexcl](https://github.com/ddemidov/vexcl)
library) leads to an internal compiler error:
$ cat strip_typedefs_ice.cpp
#include memory
typedef int32_t cl_int __attribute__((aligned(4)));
struct buffer_unmapper {
void operator()(cl_int* ptr) const {
}
};
typedef std::unique_ptrcl_int[], buffer_unmapper mapped_array;
$ g++ -c -std=c++11 strip_typedefs_ice.cpp
strip_typedefs_ice.cpp:7:50: internal compiler error: in strip_typedefs, at
cp/tree.c:1369
typedef std::unique_ptrcl_int[], buffer_unmapper mapped_array;
^
[Bug middle-end/66110] uint8_t memory access not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||alias, missed-optimization
Status|RESOLVED|NEW
Last reconfirmed||2015-05-12
CC||rguenth at gcc dot gnu.org
Component|tree-optimization |middle-end
Resolution|FIXED |---
Ever confirmed|0 |1
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
So what happens is that GCC sees
_3 = p_2(D)-p1;
_3-f2 = 9;
_5 = p_2(D)-p1;
_5-f2 = 10;
and to remove the first store it first has to prove that _3 and _5 are equal.
CSE cannot prove this because it thinks the store to _3-f2 can clobber the
value at p_2(D)-p1 (if p-p1 points to p).
get_alias_set (_3-f2) returns 0, the alias oracle has special code to also
consider the alias set of the base objects:
/* Do type-based disambiguation. */
if (base1_alias_set != base2_alias_set
!alias_sets_conflict_p (base1_alias_set, base2_alias_set))
return false;
but their alias sets happen to conflict because struct s2 alias set is a subset
of the struct s1 alias set (which is because alias set zero is a subset of
the struct s1 alias set...):
struct GTY(()) alias_set_entry_d {
/* The alias set number, as stored in MEM_ALIAS_SET. */
alias_set_type alias_set;
/* Nonzero if would have a child of zero: this effectively makes this
alias set the same as alias set zero. */
int has_zero_child;
(I've always questioned this... - the code that looks at has_zero_child in
alias_set_subset_of / alias_sets_conflict_p).
Index: gcc/alias.c
===
--- gcc/alias.c (revision 222996)
+++ gcc/alias.c (working copy)
@@ -470,15 +470,13 @@ alias_sets_conflict_p (alias_set_type se
/* See if the first alias set is a subset of the second. */
ase = get_alias_set_entry (set1);
if (ase != 0
- (ase-has_zero_child
- || ase-children-get (set2)))
+ ase-children-get (set2))
return 1;
/* Now do the same, but with the alias sets reversed. */
ase = get_alias_set_entry (set2);
if (ase != 0
- (ase-has_zero_child
- || ase-children-get (set1)))
+ ase-children-get (set1))
return 1;
/* The two alias sets are distinct and neither one is the
fixes this. I don't remember what broke (but I remember trying this for a few
times - maybe with also changing alias_set_subset_of which isn't that obvious).
[Bug c++/65133] [C++11] Result type deduction proceeds even though argument deduction fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65133 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Confirmed fixed for 5.1.0. I'm adding a testcase and closing the bug.
[Bug c++/65133] [C++11] Result type deduction proceeds even though argument deduction fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65133 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug tree-optimization/66101] [5/6 Regression] internal compiler error: in verify_loop_structure, at cfgloop.c:1662
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66101 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- It's DCE leaving loops broken and not marking them for fixup.
[Bug target/64691] Suboptimal register allocation for bytes comparison on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64691 --- Comment #2 from Yuri Rumyantsev ysrumyan at gmail dot com --- Created attachment 35526 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35526action=edit tset-case to reproduce and assembly file.
[Bug c++/66119] New: Regression in optimization of avx-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66119
Bug ID: 66119
Summary: Regression in optimization of avx-code
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joachim.schoeberl at tuwien dot ac.at
Target Milestone: ---
Created attachment 35525
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35525action=edit
testcode
gcc 5.1 produces a lot of scalar moves for the attached vector-class code.
gcc 4.9 generates compact code (see below).
compiled using:
gcc -O3 -mavx -S -std=c++11 testgcc.cpp
compiler version:
gcc (GCC) 5.1.1 20150505
gcc 5.1 works fine in any of the cases:
- we use a manual copy constructor instead of '= default' (line 37):
MyTSIMD (const MyTSIMD s2) : data(s2.data) { ; }
- we use the concrete vector-class instead of the template (line 45):
using MyVec = MyAVX;
- we do not use
__attribute__ ((__always_inline__))
for ComputeSomething (line 58)
Cheers, Joachim
code generated by gcc5.1:
.globl _Z12TestFunction4Vec2S_
.type _Z12TestFunction4Vec2S_, @function
_Z12TestFunction4Vec2S_:
.LFB4604:
.cfi_startproc
movq72(%rsp), %rdx
vmovapd 40(%rsp), %ymm0
movq%rdi, %rax
vmovapd 8(%rsp), %ymm1
movq%rdx, -88(%rsp)
movq80(%rsp), %rdx
movq%rdx, -80(%rsp)
movq88(%rsp), %rdx
movq%rdx, -72(%rsp)
movq96(%rsp), %rdx
movq%rdx, -64(%rsp)
movq104(%rsp), %rdx
vaddpd -88(%rsp), %ymm1, %ymm1
movq%rdx, -56(%rsp)
movq112(%rsp), %rdx
movq%rdx, -48(%rsp)
movq120(%rsp), %rdx
vmovapd %ymm1, (%rdi)
movq%rdx, -40(%rsp)
movq128(%rsp), %rdx
movq%rdx, -32(%rsp)
vaddpd -56(%rsp), %ymm0, %ymm0
vmovapd %ymm0, 32(%rdi)
vzeroupper
ret
.cfi_endproc
code generated by gcc 4.9.2:
.type _Z12TestFunction4Vec2S_, @function
_Z12TestFunction4Vec2S_:
.LFB2234:
.cfi_startproc
vmovapd 40(%rsp), %ymm0
movq%rdi, %rax
vmovapd 8(%rsp), %ymm1
vaddpd 104(%rsp), %ymm0, %ymm0
vaddpd 72(%rsp), %ymm1, %ymm1
vmovapd %ymm0, 32(%rdi)
vmovapd %ymm1, (%rdi)
vzeroupper
ret
.cfi_endproc
[Bug target/66112] __builtin_mul_overflow for int16_t emits poor code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66112 --- Comment #7 from Jeremy gcc.hall at gmail dot com --- Comment on attachment 35522 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35522 gcc5-pr66112.patch Done, PR66120
[Bug tree-optimization/66119] [5/6 Regression] in optimization of avx-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66119 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- And we indeed rely on SRA to copy propagate aggregates.
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394
--- Comment #31 from Steffen Hau steffen at hauihau dot de ---
Just a short update.
With LTO enabled, configure thinks I have a buggy GCC:
checking if gcc has a visibility bug with class-level attributes (GCC bug
26905)... yes
configure: WARNING: Your gcc is not -fvisibility=hidden safe. Disabling
visibility
I've then added -ffat-lto-objects to my ${C,CXX,Ld}FLAGS and the warning
disappeared.
The build failes at the same place, but instead of a segmentation fault I now
get a illegal instruction error:
/bin/sh: line 1: 10795 Illegal instruction SAL_USE_VCLPLUGIN=svp
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}$I/ure/lib:$I/program
$I/program/gengal.bin -env:BRAND_BASE_DIR=file://$S/instdir
-env:CONFIGURATION_LAYERS=xcsxcu:file://$I/share/registry
-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb
file://$W/ComponentTarget/comphelper/util/comphelp.component
file://$W/ComponentTarget/configmgr/source/configmgr.component
file://$W/ComponentTarget/drawinglayer/drawinglayer.component
file://$W/ComponentTarget/framework/util/fwk.component
file://$W/ComponentTarget/i18npool/util/i18npool.component
file://$W/ComponentTarget/package/source/xstor/xstor.component
file://$W/ComponentTarget/package/util/package2.component
file://$W/ComponentTarget/sax/source/expatwrap/expwrap.component
file://$W/ComponentTarget/sfx2/util/sfx.component
file://$W/ComponentTarget/svgio/svgio.component
file://$W/ComponentTarget/svx/util/svx.component
file://$W/ComponentTarget/svx/util/svxcore.component
file://$W/ComponentTarget/ucb/source/core/ucb1.component
file://$W/ComponentTarget/ucb/source/ucp/file/ucpfile1.component
file://$W/ComponentTarget/unoxml/source/service/unoxml.component
-env:UNO_TYPES= file://$I/program/types/offapi.rdb
file://$I/ure/share/misc/types.rdb -env:URE_INTERNAL_LIB_DIR=file://$I/ure/lib
-env:LO_LIB_DIR=file://$I/program --build-tree --destdir
file://$S/extras/source/gallery --name arrows --path $W/Gallery/arrows
--filenames file://$RESPONSEFILE
/home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/solenv/gbuild/Gallery.mk:72:
recipe for target
'/home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/workdir/Gallery/arrows.done'
failed
make[1]: ***
[/home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/workdir/Gallery/arrows.done]
Error 132
make[1]: *** Waiting for unfinished jobs
[Bug tree-optimization/66119] [5/6 Regression] in optimization of avx-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66119 --- Comment #7 from James Greenhalgh jgreenhalgh at gcc dot gnu.org --- (In reply to Richard Biener from comment #5) DEFPARAM (PARAM_SRA_MAX_SCALARIZATION_SIZE_SPEED, sra-max-scalarization-size-Ospeed, Maximum size, in storage units, storage units! But the value seems to be in bits? It gets used as if (tree_to_uhwi (TYPE_SIZE (TREE_TYPE (var))) = max_scalarization_size) Well, that part should have been covered by: + unsigned max_scalarization_size += (optimize_function_for_size_p (cfun) + ? PARAM_VALUE (PARAM_SRA_MAX_SCALARIZATION_SIZE_SIZE) + : PARAM_VALUE (PARAM_SRA_MAX_SCALARIZATION_SIZE_SPEED)) + * BITS_PER_UNIT; From the original patch, Looks like get_move_ratio returns different things at SRA time (if I re-call it) and the time it gets invoked in toplev.c. But, yes these parameters will cause a difference in code generation if previously MOVE_RATIO could return different values at different times, as it might well have if target_option_override set up a structure used by MOVE_RATIO. The patch I applied carries the hidden assumption that MOVE_RATIO is constant. Clearly there are a number of situations we might not want that to be true (say, for switchable targets - which I don't think your patch will help).
[Bug sanitizer/64839] libsanitizer shouldn't require rpc/xdr.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64839 --- Comment #14 from Thierry Reding thierry.reding at gmail dot com --- Thanks Yury.
[Bug target/66112] __builtin_mul_overflow for int16_t emits poor code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66112 --- Comment #3 from Jeremy gcc.hall at gmail dot com --- Related FYI, Few instructions on ARM set the overflow flag. Two that do are 32-bit add and subtract. For these two, GCC could just emit adds followed by bvs Instead it produces:- bl atoi@ add r1, r4, r0 @ tmp121, a, b cmp r0, #0 @ b, blt .L4 @, cmp r1, r4 @ tmp121, a bge .L5 @, b .L3 @ .L4: cmp r1, r4 @ tmp121, a ble .L5 @,
[Bug target/65955] [arm] ICE during movcond_addsi split
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65955 --- Comment #12 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Tue May 12 09:15:09 2015 New Revision: 223049 URL: https://gcc.gnu.org/viewcvs?rev=223049root=gccview=rev Log: [ARM] Fix PR 65955: Do not take REGNO on non-REG operand in movcond_addsi PR target/65955 * config/arm/arm.md (movcond_addsi): Check that operands[2] is a REG before taking its REGNO. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md
[Bug target/65955] [arm] ICE during movcond_addsi split
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65955 ktkachov at gcc dot gnu.org changed: What|Removed |Added Known to work||6.0 Target Milestone|--- |5.2 Known to fail||4.9.3, 5.0 --- Comment #13 from ktkachov at gcc dot gnu.org --- Fixed on trunk. Will be backporting if testing on trunk shows no problem and testing on branches goes ok
[Bug target/64691] Suboptimal register allocation for bytes comparison on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64691
Yuri Rumyantsev ysrumyan at gmail dot com changed:
What|Removed |Added
CC||ysrumyan at gmail dot com
--- Comment #1 from Yuri Rumyantsev ysrumyan at gmail dot com ---
I found another register allocation deficiency which can be exhibited at the
attached test-case extracted from important benchmark. If we look at inner loop
for(i = 0; i size; i++) {
byte xr, xg, xb, t1;
sbyte t2, t3;
x1 = read[0];
x2 = read[1];
x3 = read[2];
t1 = (byte) (((C1 * x1) + (C2 * x2) + (C3 * x3) +
(1 (SCALE - 1))) SCALE);
t2 = (sbyte) (((C4 * x1) + (C5 * x2) + (C6 * x3) +
(1 (SCALE - 1))) SCALE);
t3 = (sbyte) (((C7 * x1) + (C8 * x2) + (C9 * x3) +
(1 (SCALE - 1))) SCALE);
write[0] = t1;
write[1] = (byte) t2;
write[2] = (byte) t3;
read += 3;
write += 3;
}
we can see that 7 registers is enough to keep all variable (except for upper
loop bound): 3 registers for x1,x2,x3, 2 registers for read and write pointers
and 2 registers for computation one for t1,t2,t3 computations and one scratch
register for multiplications (but since consumers of t1,t2,t3 is byte store
this register must belong also to Q_REQS subset, i.e. AREG,BREG,CREG or DREG).
But LRA does not perform such allocation and this leads to redundant
spill/fills and results in performance degradation. Assembly file produced 6.0
compiler with -O2 -m32 -march=slm options is attached too.
[Bug target/66112] __builtin_mul_overflow for int16_t emits poor code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66112
--- Comment #8 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Jakub Jelinek from comment #5)
Created attachment 35524 [details]
gcc6-pr66112-2.patch
And i386 mulvhi4 and umulvhi4 support. For umulvhi4, I haven't found
corresponding i386.md instruction that would emit mul{w}, so just changed
SWI48 to SWI248 iterator in that case.
No, mulw outputs to %ax:%dx pair of HImode registers! Please see [1]
[1] http://x86.renejeschke.de/html/file_module_x86_id_210.html
[Bug target/66047] [5/6 Regression] vlc compilation failure with target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66047 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org --- Mine.
[Bug tree-optimization/66123] Array of labels as values + ternary operator + pointer arithmetic = internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66123 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- $ ./cc1 -quiet x.c -O x.c: In function ‘test’: x.c:2:1: internal compiler error: Segmentation fault test (int foo) ^ 0xd7129c crash_signal /home/marek/src/gcc/gcc/toplev.c:380 0xecc3e3 propagate_rhs_into_lhs /home/marek/src/gcc/gcc/tree-ssa-dom.c:2945 0xecc660 eliminate_const_or_copy /home/marek/src/gcc/gcc/tree-ssa-dom.c:3017 0xecc7c4 eliminate_degenerate_phis_1 /home/marek/src/gcc/gcc/tree-ssa-dom.c:3054 0xecc817 eliminate_degenerate_phis_1 /home/marek/src/gcc/gcc/tree-ssa-dom.c:3061 0xecc817 eliminate_degenerate_phis_1 /home/marek/src/gcc/gcc/tree-ssa-dom.c:3061 0xecc921 execute /home/marek/src/gcc/gcc/tree-ssa-dom.c:3155 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug tree-optimization/66123] Array of labels as values + ternary operator + pointer arithmetic = internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66123
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-05-12
CC||mpolacek at gcc dot gnu.org
Component|c |tree-optimization
Ever confirmed|0 |1
--- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org ---
Confirmed, ICEs since gcc 4.6.
int
test (int foo)
{
static void *dummy[] = { a, b };
goto *((char *) b - 2 * (foo 0));
a:
b:
return 0;
}
[Bug tree-optimization/66123] Array of labels as values + ternary operator + pointer arithmetic = internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66123
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
Index: tree-ssa-dom.c
===
--- tree-ssa-dom.c (revision 223044)
+++ tree-ssa-dom.c (working copy)
@@ -2914,7 +2914,7 @@ propagate_rhs_into_lhs (gimple stmt, tre
else
val = gimple_goto_dest (use_stmt);
- if (val is_gimple_min_invariant (val))
+ if (val TREE_CODE (val) == INTEGER_CST)
{
basic_block bb = gimple_bb (use_stmt);
edge te = find_taken_edge (bb, val);
[Bug c/66122] Bad uninlining decisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
--- Comment #2 from Denis Vlasenko vda.linux at googlemail dot com ---
Tested with gcc-4.9.2. The attached testcase doesn't exhibit the bug, but
compiling the same kernel tree, with the same .config, and then running
nm --size-sort vmlinux | grep -iF ' t ' | uniq -c | grep -v '^ *1 ' | sort -rn
reveals that now other functions get wrongly deinlined:
8 0028 t acpi_os_allocate_zeroed
7 0011 t dst_output_sk
7 000b t hweight_long
5 0023 t umask_show
5 000f t init_once
4 0047 t uni2char
4 0028 t cmask_show
4 0025 t inv_show
4 0025 t edge_show
4 0020 t char2uni
4 001f t event_show
4 001d t acpi_node
4 0012 t t_stop
4 0012 t dst_discard
4 0011 t kzalloc
4 000b t udp_lib_close
4 0006 t udp_lib_hash
3 0059 t get_expiry
3 0025 t __uncore_inv_show
3 0025 t __uncore_edge_show
3 0023 t __uncore_umask_show
3 0023 t name_show
3 0022 t acpi_os_allocate
3 001f t __uncore_event_show
3 000d t cpumask_set_cpu
3 000a t nofill
...
...
For example, hweight_long:
static inline unsigned long hweight_long(unsigned long w)
{
return sizeof(w) == 4 ? hweight32(w) : hweight64(w);
}
wasn't expected by programmer to be deinlined. But it was:
81009c40 hweight_long:
81009c40: 55 push %rbp
81009c41: e8 da eb 31 00 callq 81328820
__sw_hweight64
81009c46: 48 89 e5mov%rsp,%rbp
81009c49: 5d pop%rbp
81009c4a: c3 retq
81009c4b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
I'm going to find and attach a file which deinlines hweight_long.
[Bug c/66000] Suggestion: more than one not declared in this scope per line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66000 Eric Gallager egall at gwmail dot gwu.edu changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #1 from Eric Gallager egall at gwmail dot gwu.edu --- (In reply to Michael Darling from comment #0) With the code nonExistantClass varName = nonExistantFunction(); gcc 5.1.0 gives error: `nonExistantClass' was not declared in this scope nonExistantClass varName = nonExistantFunction(); ^ It might be better if it ALSO gave: error: `nonExistantFunction' was not declared in this scope nonExistantClass varName = nonExistantFunction(); ^ idk, this might lengthen the error output considerably for files with a lot of undeclared identifiers in them...
[Bug fortran/66102] dependency mishandling with reallocation on assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66102 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-12 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- The code segfault at run time when compiled with 4.5 to 4.7 and aborts with 4.8 and above.
[Bug tree-optimization/37021] Fortran Complex reduction / multiplication not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37021 --- Comment #18 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue May 12 11:55:40 2015 New Revision: 223059 URL: https://gcc.gnu.org/viewcvs?rev=223059root=gccview=rev Log: 2015-05-12 Richard Biener rguent...@suse.de PR tree-optimization/37021 * tree-vectorizer.h (struct _slp_tree): Add two_operators flag. (SLP_TREE_TWO_OPERATORS): New define. * tree-vect-slp.c (vect_create_new_slp_node): Initialize SLP_TREE_TWO_OPERATORS. (vect_build_slp_tree_1): Allow two mixing plus/minus in an SLP node. (vect_build_slp_tree): Adjust. (vect_analyze_slp_cost_1): Likewise. (vect_schedule_slp_instance): Vectorize mixing plus/minus by emitting two vector stmts and mixing the results. * gcc.target/i386/vect-addsub.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/i386/vect-addsub.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c trunk/gcc/tree-vectorizer.h
[Bug c++/66091] [c++-concepts] Overloading of member operators based on constraints rejected; regression from r211591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66091 --- Comment #1 from Andrew Sutton andrew.n.sutton at gmail dot com --- Confirmed. Fixed in r223061. When a function declaration started with a non-function declarator, the requires-clause wasn't being attached to the right declarator object so it wasn't being added to the declaration.
[Bug target/66120] __builtin_add/sub_overflow for int32_t emit poor code on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66120 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Target|arm*-*gnueabi |arm Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-12 Ever confirmed|0 |1 --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org --- Confirmed. Looks like the ARM port needs to implement the addvmode3 and subvmode3 patterns; although those do not appear to be documented in the internals manual.
[Bug middle-end/66084] ICE:internal compiler error: in fold_convert_loc, at fold-const.c:1974
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66084 --- Comment #4 from vfdff zhongyunde at huawei dot com --- ok, it is ok based on gcc 4.9.2, thanks. $GCC492/gcc ticket_1634.c -O2
[Bug sanitizer/64839] libsanitizer shouldn't require rpc/xdr.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64839 --- Comment #18 from Geoff Nixon geoff at geoff dot codes --- Ok thanks, for other idiots like myself who can't seem to figure out how to get viewvc to generate a diff for a specific rev, a -p1 patch is: svn diff -c 223032 svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch Or if you don't have subversion installed, here: http://gist.github.com/anonymous/7f239960c46240d83a67/raw
[Bug c/66122] New: Bad uninlining decisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
Bug ID: 66122
Summary: Bad uninlining decisions
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vda.linux at googlemail dot com
Target Milestone: ---
On linux kernel build, I found thousands of cases where functions which are
expected (by programmer) to be inlined, aren't actually inlined.
The following script is used to find them:
nm --size-sort vmlinux | grep -iF ' t ' | uniq -c | grep -v '^ *1 ' | sort -rn
It caltually finds functions which have same name, size, and occur more than
once. There are a few false positives, but vast majority of them are functions
which were supposed to be inlined, but weren't:
(Count) (size) (name)
473 000b t spin_unlock_irqrestore
449 005f t rcu_read_unlock
355 0009 t atomic_inc
353 006e t rcu_read_lock
350 0075 t rcu_read_lock_sched_held
291 000b t spin_unlock
266 0019 t arch_local_irq_restore
215 000b t spin_lock
180 0011 t kzalloc
165 0012 t list_add_tail
161 0019 t arch_local_save_flags
153 0016 t test_and_set_bit
134 000b t spin_unlock_irq
134 0009 t atomic_dec
130 000b t spin_unlock_bh
122 0010 t brelse
120 0016 t test_and_clear_bit
120 000b t spin_lock_irq
119 001e t get_dma_ops
117 0053 t cpumask_next
116 0036 t kref_get
114 001a t schedule_work
106 000b t spin_lock_bh
103 0019 t arch_local_irq_disable
98 0014 t atomic_dec_and_test
83 0020 t sg_page
81 0037 t cpumask_check
79 0036 t pskb_may_pull
72 0044 t perf_fetch_caller_regs
70 002f t cpumask_next
68 0036 t clk_prepare_enable
65 0018 t pci_write_config_byte
65 0013 t tasklet_schedule
61 0023 t init_completion
60 002b t trace_handle_return
59 0043 t nlmsg_trim
59 0019 t pci_read_config_dword
59 000c t slow_down_io
...
...
Note tiny sizes of some functions. Let's take a look at atomic_inc:
static inline void atomic_inc(atomic_t *v)
{
asm volatile(LOCK_PREFIX incl %0
: +m (v-counter));
}
You would imagine that this won't ever be deinlined, right? It's one assembly
instruction. Well, it isn't always inlined. Here's the disassembly of vmlinux:
81003000 atomic_inc:
81003000: 55 push %rbp
81003001: 48 89 e5mov%rsp,%rbp
81003004: f0 ff 07lock incl (%rdi)
81003007: 5d pop%rbp
81003008: c3 retq
This can be fixed using __always_inline, but kernel developers hesitate to slap
thousands of __always_inline everywhere, the mood is that this is a compiler's
fault and it should not be accomodated for, but fixed.
This happens quite easily with -Os (IOW: with CC_OPTIMIZE_FOR_SIZE=y kernel
build), but -O2 is not immune either.
I found a file which exhibits an example of bad deinlining for both -O2 and -Os
and I'm going to attach it.
[Bug c/66123] New: Array of labels as values + ternary operator + pointer arithmetic = internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66123 Bug ID: 66123 Summary: Array of labels as values + ternary operator + pointer arithmetic = internal compiler error Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: SztfG at yandex dot ru Target Milestone: --- Created attachment 35529 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35529action=edit Preprocessed source bug.c: In function ‘test’: bug.c:1:5: internal compiler error: Segmentation fault Target: x86_64-linux-gnu gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) Code in attachment It also produces internal compiler error for ARM and ARM64 target
[Bug fortran/66089] [6 Regression] elemental dependency mishandling when derived types are involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-12 CC||vehre at gcc dot gnu.org Summary|elemental dependency|[6 Regression] elemental |mishandling when derived|dependency mishandling when |types are involved |derived types are involved Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- The code in comment 0 does not abort at run time up to revision r222352 (2015-04-23), but does so at r222398 (2015-04-24), likely r222361.
[Bug tree-optimization/66123] Array of labels as values + ternary operator + pointer arithmetic = internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66123 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
[Bug target/66120] __builtin_add/sub_overflow for int32_t emit poor code on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66120
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
Not those, but addvmode4 and subvmode4 instead (perhaps {,u}mulvmode4 if
the ISA detects multiplication overflows, also there is negvmode3).
[Bug c/66122] Bad uninlining decisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122 --- Comment #3 from Denis Vlasenko vda.linux at googlemail dot com --- Created attachment 35530 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35530action=edit Preprocessed example exhibiting a bug on gcc -4.9.2 This is a preprocessed kernel/pid.c file from kernel source. When built with -O2, it wrongly deinlines hweight_long. $ gcc -O2 -c pid.preprocessed.c -o kernel.pid.o $ objdump -dr kernel.pid.o | grep -A3 hweight_long hweight_long: 0: e8 00 00 00 00 callq 5 hweight_long+0x5 1: R_X86_64_PC32__sw_hweight64-0x4 5: c3 retq $ gcc -v 21 | tail -1 gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC)
[Bug c/66122] Bad uninlining decisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
--- Comment #1 from Denis Vlasenko vda.linux at googlemail dot com ---
Created attachment 35528
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35528action=edit
Preprocessed example exhibiting a bug
This is a preprocessed kernel/locking/mutex.c file from kernel source.
When built with either -O2 or -Os, it wrongly deinlines spin_lock() and
spin_unlock():
$ gcc -O2 -c mutex.preprocessed.c -o mutex.preprocessed.o
$ objdump -dr mutex.preprocessed.o
mutex.preprocessed.o: file format elf64-x86-64
Disassembly of section .text:
spin_unlock:
0: 80 07 01addb $0x1,(%rdi)
3: c3 retq
4: 66 66 66 2e 0f 1f 84data32 data32 nopw %cs:0x0(%rax,%rax,1)
b: 00 00 00 00 00
0010 __mutex_init:
...
0040 spin_lock:
40: e9 00 00 00 00 jmpq 45 spin_lock+0x5
41: R_X86_64_PC32 _raw_spin_lock-0x4
45: 66 66 2e 0f 1f 84 00data32 nopw %cs:0x0(%rax,%rax,1)
4c: 00 00 00 00
These functions are defined as:
static inline __attribute__((no_instrument_function)) void
spin_unlock(spinlock_t *lock)
{
__raw_spin_unlock(lock-rlock);
}
static inline __attribute__((no_instrument_function)) void spin_lock(spinlock_t
*lock)
{
_raw_spin_lock(lock-rlock);
}
and programmer's intent was that they will always be inlined.
This is with gcc-4.7.2
[Bug tree-optimization/66123] Array of labels as values + ternary operator + pointer arithmetic = internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66123
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
Or rather
Index: tree-ssa-dom.c
===
--- tree-ssa-dom.c (revision 223044)
+++ tree-ssa-dom.c (working copy)
@@ -2918,6 +2918,8 @@ propagate_rhs_into_lhs (gimple stmt, tre
{
basic_block bb = gimple_bb (use_stmt);
edge te = find_taken_edge (bb, val);
+ if (te)
+ {
edge_iterator ei;
edge e;
gimple_stmt_iterator gsi;
@@ -2961,6 +2963,7 @@ propagate_rhs_into_lhs (gimple stmt, tre
te-flags |= EDGE_FALLTHRU;
if (te-probability REG_BR_PROB_BASE)
te-probability = REG_BR_PROB_BASE;
+ }
}
}
}
if computed goto removal should work.
[Bug rtl-optimization/64616] Redundant ldr when accessing var inside and outside a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64616 --- Comment #4 from Thomas Preud'homme thopre01 at gcc dot gnu.org --- Author: thopre01 Date: Wed May 13 05:39:14 2015 New Revision: 223113 URL: https://gcc.gnu.org/viewcvs?rev=223113root=gccview=rev Log: 2015-05-13 Thomas Preud'homme thomas.preudho...@arm.com gcc/ PR rtl-optimization/64616 * loop-invariant.c (can_move_invariant_reg): New. (move_invariant_reg): Call above new function to decide whether instruction can just be moved, skipping creation of temporary register. gcc/testsuite/ PR rtl-optimization/64616 * gcc.dg/loop-8.c: New test. * gcc.dg/loop-9.c: New test. Added: trunk/gcc/testsuite/gcc.dg/loop-8.c trunk/gcc/testsuite/gcc.dg/loop-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/loop-invariant.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/65908] [5/6 Regression] ICE: in expand_thunk, at cgraphunit.c:1700
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65908 --- Comment #7 from Martin Liška marxin at gcc dot gnu.org --- Created attachment 35533 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35533action=edit Suggested fix I've been testing following patch for 5.1.0 branch. I'm wondering if comparison of just TYPE_ARG_TYPES is sufficient?
[Bug fortran/66089] [6 Regression] elemental dependency mishandling when derived types are involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089 --- Comment #4 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #3) The code in comment 0 does not abort at run time up to revision r222352 (2015-04-23), but does so at r222398 (2015-04-24), likely r222361. Yes, probably the change in gfc_add_loop_ss_code (which comment #1 removes).
[Bug c++/65133] [C++11] Result type deduction proceeds even though argument deduction fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65133 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Tue May 12 09:03:04 2015 New Revision: 223047 URL: https://gcc.gnu.org/viewcvs?rev=223047root=gccview=rev Log: 2015-05-12 Paolo Carlini paolo.carl...@oracle.com PR c++/65133 * g++.dg/cpp0x/trailing10.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/trailing10.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/66112] __builtin_mul_overflow for int16_t emits poor code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66112
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 35524
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35524action=edit
gcc6-pr66112-2.patch
And i386 mulvhi4 and umulvhi4 support. For umulvhi4, I haven't found
corresponding i386.md instruction that would emit mul{w}, so just changed SWI48
to SWI248 iterator in that case.
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||mikestump at comcast dot net Target Milestone|--- |5.2 Summary|[5.1.0 regression] (stage |[5 regression] (stage 2) |2) build/genmatch segfaults |build/genmatch segfaults in |in operand::gen_transform |operand::gen_transform |(gcc/hash-table.h:223) |(gcc/hash-table.h:223) --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Douglas Mencken from comment #5) (In reply to rguent...@suse.de from comment #4) Can you build stage2 with debuginfo? (--without-build-config at configure) That should imrpove the backtrace. Thanks, Richard. Sure I can. Here you go: (gdb) bt #0 0xe208 in operand::gen_transform () at ../../gcc-5.1.0/gcc/hash-table.h:223 #1 0x8530 in get_operator (id=0x808bec tcc_comparison) at ../../gcc-5.1.0/gcc/genmatch.c:1495 #2 0x9ef8 in parser::parse_operator_list (this=0xb698) at ../../gcc-5.1.0/gcc/genmatch.c:2941 #3 0xd190 in parser::parse_pattern (this=0xb698) at ../../gcc-5.1.0/gcc/hash-table.h:223 #4 0xe19c in parser::parser (this=0xb698, r_=0xb4f8) at ../../gcc-5.1.0/gcc/hash-table.h:223 #5 0x0005f3ac in main (argc=3146720, argv=0xb4f8) at ../../gcc-5.1.0/gcc/genmatch.c:3711 Current language: auto; currently c++ Huh, the line numbers don't make any sense. I wonder what ld warning: atom sorting error for operand::gen_transform(__sFILE*, char const*, bool, int, char const*, capture_info*, dt_operand**, bool) and hash_tableid_base, xcallocator, false::find_with_hash(id_base const*, unsigned int) in build/genmatch.o means and if that explains things? Like it ends up calling the wrong function because of a linker bug? Can you paste the linker command for linking stage2 build/genmatch and the output when -v -Wl,-v -Wl,-debug is appended? As far as I understand ld on ppc-darwin is a GNU ld variant, correct? I can't find anything in current binutils though. Mike?
[Bug c++/66119] [5/6 Regression] in optimization of avx-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66119 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. We expand from bb 2: a$data_13 = MEM[(struct Vec2 *)a]; a$32$data_14 = MEM[(struct Vec2 *)a + 32B]; b = b; v2_15 = MEM[(struct Vec2 *)b]; v2$32_16 = MEM[(struct Vec2 *)b + 32B]; _7 = a$32$data_14 + v2$32_16; _10 = a$data_13 + v2_15; MEM[(struct Vec2 *)retval] = _10; MEM[(struct Vec2 *)retval + 32B] = _7; return retval; in GCC 5 (note the b = b assignment) while 4.9 sees bb 2: a$data_4 = MEM[(struct Vec2 *)a]; a$32$data_13 = MEM[(struct Vec2 *)a + 32B]; v2_14 = MEM[(struct Vec2 *)b]; v2$32_15 = MEM[(struct Vec2 *)b + 32B]; _7 = a$32$data_13 + v2$32_15; _10 = a$data_4 + v2_14; MEM[(struct Vec2 *)retval] = _10; MEM[(struct Vec2 *)retval + 32B] = _7; return retval;
[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66066 --- Comment #8 from clyon at gcc dot gnu.org --- Can we consider moving this to -pedantic as suggested by Richard in comment #4? Full compiler builds are broken because of this. Thanks
[Bug c++/59224] [4.7/4.8/4.9 Regression] std::uncaught_exception returns true while constructing exception.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59224 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to li xin from comment #8) It will lead to the lsb test caes /libstdcxx-t2c/tests/LanguageSupport/LanguageSupport FAIL. So I want to know the right return value of std::uncaught_exception() (inside exception-constructor). What isn't clear about the bug report? The right value is the one G++ gives now. The LSB test is wrong.
