[Bug sanitizer/65662] AddressSanitizer CHECK failed: ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:835 ((res)) ((kNumPossibleRegions)) (0x3ffb49, 0x80000)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65662 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to vekumar from comment #6) For 42 bit VA, I have to change the SANITIZER_MMAP_RANGE_SIZE to 1 42. Sure. Also compiler has to add the shadow offset instead of Oring it. You don't, see my patch. As I said, the hard part is making sure all 3 layouts work with the same libasan library - the problem is that the library assumes some decisions (like whether to use 32-bit or 64-bit allocator) have to be done at library compile time, when for aarch64 they really have to be done at runtime.
[Bug target/65647] [5 Regression] GCC won't stop when compile for armv6-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65647 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- So fixed?
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #22 from drikosev at otenet dot gr --- Created attachment 35234 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35234action=edit cleanup if a declaration type spec is erroneous Let's see if the function names are properly printed into the context surrounding changes; the GNU patch guidelines suggest it!
[Bug sanitizer/65662] AddressSanitizer CHECK failed: ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:835 ((res)) ((kNumPossibleRegions)) (0x3ffb49, 0x80000)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65662 --- Comment #8 from vekumar at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #7) (In reply to vekumar from comment #6) For 42 bit VA, I have to change the SANITIZER_MMAP_RANGE_SIZE to 1 42. Sure. Also compiler has to add the shadow offset instead of Oring it. You don't, see my patch. As I said, the hard part is making sure all 3 layouts work with the same libasan library - the problem is that the library assumes some decisions (like whether to use 32-bit or 64-bit allocator) have to be done at library compile time, when for aarch64 they really have to be done at runtime. Hi Jakub, It was decided to make ASAN work for 42 bit VA without changing the default allocator (32bit) and the default shadow offset (136). Please see thread https://groups.google.com/forum/#!topic/address-sanitizer/YzYRJEvVimw. On 42 bit VA with default settings, I found that some cases (LLVM ASAN tests) were failing because the compiler (LLVM) does Oring of shadow offset and ASAN library code adds the shadow offset. Both access resulted in valid memory and but we were poisoning the wrong shadow memory. Now your patch turns on the 64 bit allocator. I agree to do this we need to dynamically detect VA at runtime. Can you please join the thread and post your comments there.
[Bug ipa/65478] [5 regression] crafty performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478 --- Comment #25 from Jan Hubicka hubicka at gcc dot gnu.org --- Crafty perfomrance is back (with a combination of better heuristics and increase of inlining limits), eon is not, at least not in all configurations. We have separate eon PR, so I am closing this one.
[Bug libstdc++/65675] New: make bootstrap fails when configured with --disable-hosted-libstdcxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65675 Bug ID: 65675 Summary: make bootstrap fails when configured with --disable-hosted-libstdcxx Product: gcc Version: 4.8.4 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ian at ianshome dot com Linux Ubuntu-14-04 3.13.0-46-generic ../gcc_4_8_4/configure --enable-cxx-flags=-fno-exceptions \ --prefix=/opt/gcc_4_8_4 \ --enable-languages=c,c++ \ --disable-hosted-libstdcxx make bootstrap ... Fails with: Entering directory `/mnt/gcc-build/gcc' /mnt/gcc-build/./prev-gcc/xg++ -B/mnt/gcc-build/./prev-gcc/ -B/opt/gcc_4_8_4/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/mnt/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/mnt/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/mnt/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/mnt/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/mnt/gcc/libstdc++-v3/libsupc++ -L/mnt/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/mnt/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -g -O2 -gtoggle -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc -o build/genmddeps \ build/genmddeps.o build/read-md.o build/errors.o .././libiberty/libiberty.a /usr/bin/ld: cannot find -lstdc++ collect2: error: ld returned 1 exit status make[3]: *** [build/genmddeps] Error 1 make[3]: Leaving directory `/mnt/gcc-build/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/mnt/gcc-build' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/mnt/gcc-build' make: *** [bootstrap] Error 2
[Bug target/65674] New: stack smashing protector must be controllable per-function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65674 Bug ID: 65674 Summary: stack smashing protector must be controllable per-function Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: stsp at users dot sourceforge.net Hello. On x86 (both 32 and 64), linux doesn't set FS and GS registers to the sane values when invoking the signal handler. Therefore the first thing the sig handler should do is to restore these registers if the program itself can ever modify them. Unfortunately gcc uses them in prolog/epilog for ssp, and so the stack smashing detected. I think attribute no_instrument_function or naked should do that, but currently they don't, which is almost a bug, at least no_instrument_function is supported but doesn't give the desired effect. I can't even think of any reasonable work-around. For example I could do the small asm wrapper that restores these regs, but on x86_64 this is not enough: you need to set their base separately, via the prctl() syscall. Doing this all from asm is too nasty, I really think gcc should allow writing the proper sighandler.
[Bug c/65673] New: Compound literal with initializer for zero-sized array drops other initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65673
Bug ID: 65673
Summary: Compound literal with initializer for zero-sized array
drops other initializers
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: stilor at att dot net
I am seeing a strange behavior when a compound initializer is used in a
structure initialization. A test case:
[[[
struct s {
int y;
unsigned long *x;
};
struct s foo = {
.y = 25,
.x = (unsigned long [SZ]){},
};
]]]
If SZ is defined to non-zero, the expected output is produced:
[[[
/tmp$ gcc -S -o- 1.c -Wall -DSZ=1
.file1.c
.local__compound_literal.0
.comm__compound_literal.0,8,8
.globlfoo
.data
.align 16
.typefoo, @object
.sizefoo, 16
foo:
.long25
.zero4
.quad__compound_literal.0
.identGCC: (Ubuntu 4.9.1-16ubuntu6) 4.9.1
.section.note.GNU-stack,,@progbits
]]]
If SZ is zero, the initializer for .y (.y = 25) member is dropped as well:
[[[
/tmp$ gcc -S -o- 1.c -Wall -DSZ=0
.file1.c
.globlfoo
.bss
.align 16
.typefoo, @object
.sizefoo, 16
foo:
.zero16
.identGCC: (Ubuntu 4.9.1-16ubuntu6) 4.9.1
.section.note.GNU-stack,,@progbits
]]]
Tested with GCC 4.6.3 and 4.9.1, both exhibit the same behavior.
With -Wextra, the code rightfully complains that the initializer for .x is
missing - but why the .y initializer is dropped even if there is no initializer
for .x?
In the mailing list, this was some discussion of this issue:
[[[
But in this case, the code attempts to create an unnanmed temporary array of
zero elements which, IMO, makes no sense. At the same time, I wouldn't expect
gcc to simply omit the initialization for foo.x. I suggest to open a gcc bug
for it.
]]]
I'd add that this was a reduced test case from a bigger aggregate type - which
was an array of such structures. When one of the elements became unused and the
size of the bitmap (which was the purpose of the compound literal initializer)
was set to zero, the whole array lost its initializers - i.e., even other
'struct s' members of the array, not just the member with a zero-sized array
compound literal.
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #16 from Dominique d'Humieres dominiq at lps dot ens.fr ---
As it seems the problem with the program bug.f90 is that the generic
attribute is set in a symbol as the parser tries to match a declaration
type specification; but finally, the statement isn't matched as such
and the generic attribute wasn't cleared.
So, the attached patch makes the cleanup, without causing the regressions
listed in comment 9.
IMO the patch addresses the root of the problem and prevents the ICEs in the
PRs listed in comment 9. However it causes 3000+ failures in the test suite, so
the filter you apply is not narrow enough.
The question here is if gfortran had to print an error message for
this program:
module types
public :: undefined
end module types
write (*,*) undefined types!
end
Why should it without implicit none?
Your patches do not follow the GNU coding standards:
http://www.gnu.org/prep/standards/
The last patch should look as
--- ../_clean/gcc/fortran/decl.c2015-03-25 14:07:04.0 +0100
+++ gcc/fortran/decl.c2015-04-05 13:02:38.0 +0200
@@ -4427,6 +4427,31 @@ ok:
gfc_free_data_all (gfc_current_ns);
cleanup:
+ //pr59016 in gfc_match_data_decl; cleanup the garbages
+ gfc_symbol *csym = NULL;
+ if (current_ts.u.derived current_ts.u.derived-name)
+{
+ char iname[129];
+ iname[128] = 0;
+ for (int i = 0; i 128; i++)
+{
+ iname[i] = current_ts.u.derived-name[i];
+ if (current_ts.u.derived-name[i] == 0)
+break;
+}
+ iname[0] = TOLOWER(iname[0]);
+ for (int i = 0; i 4; i++)
+{
+ gfc_find_symbol (iname, NULL, i, csym) ;
+ if (csym csym-generic
+ (csym-generic-sym == current_ts.u.derived))
+ {
+ csym-generic = NULL;
+ break;
+ }
+}
+}
+ ///pr59016
gfc_free_array_spec (current_as);
current_as = NULL;
return m;
(note that I may have done some errors myself). In addition you should comment
what you are trying to do.
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #18 from Dominique d'Humieres dominiq at lps dot ens.fr ---
With an additional filtering on (m == MATCH_ERROR), i.e. with the following
patch, the ICEs are fixed without regression
--- ../_clean/gcc/fortran/decl.c2015-03-25 14:07:04.0 +0100
+++ gcc/fortran/decl.c2015-04-05 16:17:34.0 +0200
@@ -4427,6 +4437,32 @@ ok:
gfc_free_data_all (gfc_current_ns);
cleanup:
+ //pr59016 in gfc_match_data_decl; cleanup the garbages
+ gfc_symbol *csym = NULL;
+ if ((m == MATCH_ERROR) current_ts.u.derived
+ current_ts.u.derived-name)
+{
+ char iname[129];
+ iname[128] = 0;
+ for (int i = 0; i 128; i++)
+{
+ iname[i] = current_ts.u.derived-name[i];
+ if (current_ts.u.derived-name[i] == 0)
+break;
+}
+ iname[0] = TOLOWER(iname[0]);
+ for (int i = 0; i 4; i++)
+{
+ gfc_find_symbol (iname, NULL, i, csym) ;
+ if (csym csym-generic
+ (csym-generic-sym == current_ts.u.derived))
+ {
+ csym-generic = NULL;
+ break;
+ }
+}
+}
+ ///pr59016
gfc_free_array_spec (current_as);
current_as = NULL;
return m;
Further testing in progress. A few comments:
(1) The patch could probably be simplified,
(2) Its conformity with the GNU coding style has to be checked.
(3) It has to go to fort...@gcc.gnu.org and gcc-patc...@gcc.gnu.org for review.
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #17 from Dominique d'Humieres dominiq at lps dot ens.fr --- I have forgotten to give a sample of the failing tests with the patch in comment 15: FAIL: gfortran.dg/coarray/alloc_comp_3.f90 -fcoarray=single -O2 -latomic (test for excess errors) FAIL: gfortran.dg/coarray/alloc_comp_3.f90 -fcoarray=lib -O2 -lcaf_single -latomic (test for excess errors) FAIL: gfortran.dg/coarray/poly_run_1.f90 -fcoarray=single -O2 -latomic (test for excess errors) FAIL: gfortran.dg/coarray/poly_run_1.f90 -fcoarray=lib -O2 -lcaf_single -latomic (test for excess errors) FAIL: gfortran.dg/coarray/poly_run_2.f90 -fcoarray=single -O2 -latomic (test for excess errors) FAIL: gfortran.dg/coarray/poly_run_2.f90 -fcoarray=lib -O2 -lcaf_single -latomic (test for excess errors) FAIL: gfortran.dg/abstract_type_3.f03 -O (test for errors, line 38) FAIL: gfortran.dg/abstract_type_3.f03 -O (test for errors, line 44) FAIL: gfortran.dg/abstract_type_3.f03 -O (test for errors, line 48) FAIL: gfortran.dg/abstract_type_3.f03 -O (test for excess errors) FAIL: gfortran.dg/abstract_type_4.f03 -O (test for excess errors) FAIL: gfortran.dg/abstract_type_6.f03 -O (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -O2 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -O3 -g (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -Os (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_12.f03 -g -flto (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -O2 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -O3 -g (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -Os (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_13.f08 -g -flto (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -O2 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -O3 -g (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -Os (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_14.f08 -g -flto (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O2 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_8.f90 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_8.f90 -O1 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -Os (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_8.f90 -O2 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -g -flto (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_8.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_3.f90 -O0 (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_8.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_3.f90 -O1 (test
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #15 from drikosev at otenet dot gr --- Created attachment 35230 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35230action=edit altered patch for the regressions reported in comment 11 Hi, As it seems the problem with the program bug.f90 is that the generic attribute is set in a symbol as the parser tries to match a declaration type specification; but finally, the statement isn't matched as such and the generic attribute wasn't cleared. So, the attached patch makes the cleanup, without causing the regressions listed in comment 9. The question here is if gfortran had to print an error message for this program: module types public :: undefined end module types write (*,*) undefined types! end --- PS: I've not checked out the source code from a repo, so the attached patch is just the output of the diff command (not svn diff).
[Bug target/65647] [5 Regression] GCC won't stop when compile for armv6-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65647 --- Comment #5 from Yvan Roux yroux at gcc dot gnu.org --- Created attachment 35229 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35229action=edit testcase that fails also on 4.9
[Bug target/65647] [5 Regression] GCC won't stop when compile for armv6-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65647 Yvan Roux yroux at gcc dot gnu.org changed: What|Removed |Added CC||yroux at gcc dot gnu.org --- Comment #4 from Yvan Roux yroux at gcc dot gnu.org --- I was about to report the same issue which occurs during the build of videolan x264 build. Vlad patch fixes the issue on trunk, but with that testcase the problem is also present in 4.9 branch (it occurs this time in ARM mode on armv6 architecture). To be backported on 4.9 the rematerialization code as to be removed from the patch, I'll submit the patch on the mailing list. command line to reproduce the problem: cc1 -O3 -marm -march=armv6 -std=c99 a.c
[Bug libstdc++/61347] std::distance(list.first(),list.end()) in O(1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61347 --- Comment #4 from Marc Glisse glisse at gcc dot gnu.org --- Created attachment 35231 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35231action=edit Overload of __distance Here is one way to do it (I will probably protect the new code with defined(__OPTIMIZE__) as well, if we keep __builtin_constant_p). (Looking at the generated code, I was surprised to notice that _M_hook and _M_unhook are in src, they seem rather small for that)
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #19 from drikosev at otenet dot gr --- Ok, I'll send a patch to the recommended addresses as soon as I read the GNU coding standards. Yet, my impression is that perhaps the patch should be a bit more complex; in example, I think that the generic interface is introduced to a list and one has to remove it and restore to old value of the field generic to the symbol. Also, I think that the additional test could be: ( m != MATCH_OK ) Thank you for your patience to run the tests.
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #20 from Dominique d'Humieres dominiq at lps dot ens.fr --- Also, I think that the additional test could be: ( m != MATCH_OK ) I don't think so: the block in the patch will be reached for (m == MATCH_NO) and I think this leads to the regressions.
[Bug sanitizer/65662] AddressSanitizer CHECK failed: ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:835 ((res)) ((kNumPossibleRegions)) (0x3ffb49, 0x80000)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65662 vekumar at gcc dot gnu.org changed: What|Removed |Added CC||vekumar at gcc dot gnu.org --- Comment #6 from vekumar at gcc dot gnu.org --- For 42 bit VA, I have to change the SANITIZER_MMAP_RANGE_SIZE to 1 42. Also compiler has to add the shadow offset instead of Oring it. I am planning to post a patch in LLVM. As Kostya said we can discuss in that thread.
[Bug middle-end/65665] [5.0 Regression]: g++.dg/torture/pr64378.C -O2 -flto -fno-use-linker-plugin -flto-partition=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65665 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Martin Liška marxin at gcc dot gnu.org --- Fixed in 5.0.
[Bug middle-end/65665] [5.0 Regression]: g++.dg/torture/pr64378.C -O2 -flto -fno-use-linker-plugin -flto-partition=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65665 --- Comment #9 from Martin Liška marxin at gcc dot gnu.org --- Author: marxin Date: Sun Apr 5 17:17:29 2015 New Revision: 221872 URL: https://gcc.gnu.org/viewcvs?rev=221872root=gccview=rev Log: Fix PR ipa/65665 PR ipa/65665 * ipa-icf.c (sem_function::equals_wpa): Verify that IPA CP has computed data structure. (sem_item_optimizer::update_hash_by_addr_refs): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf.c
[Bug testsuite/65484] FAIL: g++.dg/vect/pr36648.cc on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65484 Martin Sebor msebor at gcc dot gnu.org changed: What|Removed |Added Severity|minor |normal
[Bug testsuite/65484] FAIL: g++.dg/vect/pr36648.cc on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65484 Martin Sebor msebor at gcc dot gnu.org changed: What|Removed |Added Severity|normal |minor
[Bug target/65535] powerpc64-freebsd build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65535
Martin Sebor msebor at gcc dot gnu.org changed:
What|Removed |Added
Target|powerpc64-freebsd |*-*-freebsd
--- Comment #4 from Martin Sebor msebor at gcc dot gnu.org ---
This isn't powerpc64 specific. I didn't specify a FreeBSD version when
configuring gcc (i.e., I set --target=powerpc64-freebsd) assuming configure
would default to some supported version. The code in gcc/config.gcc then
results in FBSD_MAJOR being defined but empty. The patch below lets me build
stage1 (I don't have a FreeBSD sysroot to do a full bootstrap):
index cb08a5c..c668738 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -664,7 +664,7 @@ case ${target} in
gas=yes
gnu_ld=yes
fbsd_major=`echo ${target} | sed -e 's/.*freebsd//g' | sed -e 's/\..*//g'`
- tm_defines=${tm_defines} FBSD_MAJOR=${fbsd_major}
+ tm_defines=${tm_defines} FBSD_MAJOR=${fbsd_major:-3}
tmake_file=t-slibgcc
case ${enable_threads} in
no)
If supplying a default version doesn't seem like a good idea another option
might be to fail early, during the configure step.
[Bug target/65535] powerpc64-freebsd build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65535 Martin Sebor msebor at gcc dot gnu.org changed: What|Removed |Added Severity|normal |minor
[Bug target/65647] [5 Regression] GCC won't stop when compile for armv6-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65647 --- Comment #6 from Yvan Roux yroux at gcc dot gnu.org --- Author: yroux Date: Sun Apr 5 19:06:43 2015 New Revision: 221873 URL: https://gcc.gnu.org/viewcvs?rev=221873root=gccview=rev Log: gcc/ 2015-04-05 Yvan Roux yvan.r...@linaro.org Backport from trunk r221867 2015-04-04 Vladimir Makarov vmaka...@redhat.com PR target/65647 * lra.c (lra): Stop updating lra_constraint_new_regno_start after switching off inheritance. gcc/testsuite/ 2015-04-05 Yvan Roux yvan.r...@linaro.org Backport from trunk r221867 2015-04-04 Vladimir Makarov vmaka...@redhat.com PR target/65647 * gcc.target/arm/pr65647.c: New. * gcc.target/arm/pr65647-2.c: New. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/pr65647-2.c branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/pr65647.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/lra.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #21 from drikosev at otenet dot gr --- Created attachment 35232 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35232action=edit cleanup if a declaration type spec is erroneous Finally, I've sent for review to the recommended recipients the attached patch, which is suitable for gcc5.
[Bug c++/63579] New attribute for empty member optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63579 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Attachment #33750|0 |1 is obsolete|| --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org --- Created attachment 35233 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35233action=edit Handle empty members as bases Slight update to mark classes with only empty members as empty, and reject the attribute when it is applied to something that isn't a field declaration.
