[Bug pch/65550] [5 Regression] ICE (segfault) with pch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65550 --- Comment #5 from Mikhail Maltsev --- Or even simpler: #!/bin/bash mkdir -p ./src mkdir -p ./build/src/preproc.h.gch touch ./src/preproc.h cat << EOF >./src/include.h #include "src/preproc.h" /* line 1 */ /* line 2 */ EOF cat << EOF >./src/source.cpp #include "include.h" /* a single line with at least 128 columns and one token */ token EOF cd ./build cc1plus ../src/preproc.h --output-pch=src/preproc.h.gch/pch_file cc1plus -I . ../src/source.cpp
[Bug fortran/65089] FAIL: gfortran.dg/io_real_boz(2|_[45]).f90 when tested with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65089
Dominique d'Humieres changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||kcc at gcc dot gnu.org
--- Comment #6 from Dominique d'Humieres ---
I confirme that the patch in comment 3 "fixes" the PR. I have added a line
printf("len=%d, strlen(p)=%d\n", len, strlen(p));
after the 'for' loop and AFAICT len == strlen(p), however runing the code
compiled with -fsanitize=address still gives the error.
So I am wondering if this PR is not a sanitizer false positive when using
strlen.
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #11 from Dominique d'Humieres --- > In a slightly altered patched, I've added a precondition which examines > first the locus of the current symbol and finally the error reported seems > to comply with the testsuites. Indeed, however the new patch does not prevent the ICEs. AFAICT the basic problem is not with p->sym->declared_at.lb, but with p->sym->name. I have tried to check for p->sym->name==0 which happen sometime, but not always in a seemingly random way. When p->sym->name!=0 and an ICE, p->sym->name seems malformed. So I suspect a bug upstream where the pointer p->sym->name is not reset to NULL. BTW your patches do not follow the gnu coding style.
[Bug libstdc++/65500] [5 Regression] FAIL: 17_intro/headers/c++2014/all_attributes.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65500 --- Comment #6 from Jonathan Wakely --- After some discussion with Torvald I'm wondering whether it would be better to never use the PTHREAD_RWLOCK_INITIALIZER macro anyway, so we can initialize the rwlock with (non-standard) attributes such as PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP
[Bug c++/59499] Probably optimization error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59499 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-04-04 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- A self-contained (minimized) reproducer is always a requirement.
[Bug c++/59716] variadic template multiple parameter pack expansion fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59716 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-04 Ever confirmed|0 |1
[Bug c++/59795] Invalid use of "this" in a local class not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59795 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-04 Ever confirmed|0 |1
[Bug fortran/65469] [4.8/4.9/5 Regression] ICE on bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65469 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Dominique d'Humieres --- Dup. *** This bug has been marked as a duplicate of bug 59016 ***
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 Dominique d'Humieres changed: What|Removed |Added CC||daniel.price at monash dot edu --- Comment #12 from Dominique d'Humieres --- *** Bug 65469 has been marked as a duplicate of this bug. ***
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #13 from drikosev at otenet dot gr --- Hi Dominiq, The new patch (gcc-4.8.4) worked as the older one but since the locus is corrupted I'm not surprised that a test case you tried failed. Could you post it here please? The corrupted locus is the reason that the patch 65469, submitted by Janus, doesn't work also; the "p->sym->name" sometimes is not null but it points to an invalid location and so one cannot use it in a comparison: if (p->sym->name != NULL ) //segmentation fault! Since the locus is corrupted, in my first patch I avoided to examine it whenever we are about to print an error and the referenced locus was available; which obviously invalidated some test cases in comment 9. To reset the name to null, one needs to figure out where the symbol is created (or assigned to p) which is something I don't know at the moment. With regard to the coding style, I'd like to ask for some indexes (e.g. gnu guideline or something like that). Regards, Ev. Drikos
[Bug c++/32676] [cxx0x branch] incorrect member address when using delegate constructors and virtual inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32676 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|gcc-bugs at gcc dot gnu.org| Known to work||4.8.0, 4.9.0, 5.0 Resolution|--- |WORKSFORME --- Comment #2 from Paolo Carlini --- I can't reproduce this anymore, not even with 4_7.
[Bug c++/38068] Friend Functions of the Base accessing Derived Class Members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38068 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|anubhav.saxena at wipro dot com, | |gcc-bugs at gcc dot gnu.org| Known to work||4.8.0, 4.9.0, 5.0 Resolution|--- |WORKSFORME --- Comment #3 from Paolo Carlini --- Fixed long time ago.
[Bug fortran/59024] ICE: after printing certain error messages, the compiler seg faults.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59024 --- Comment #2 from Dominique d'Humieres --- AFAICT the errors with the trunk (5.0) are now pr59024.f90:6.6: TYPE tc 1 Error: Syntax error in PUBLIC statement at (1) pr59024.f90:7.5: END TYPE tc 1 Error: Expecting END MODULE statement at (1) pr59024.f90:15.12: TYPE(tc) t 1 Error: Derived type 'tc' at (1) is being used before it is defined pr59024.f90:17.14: END MODULE mtc 1 Error: Procedure 'C_PTR_1' in generic interface 'tc' at (1) is neither function nor subroutine without any ICE. The change of behavior occurred between revisions r214073 (2014-08-17, ICE) and r214113 (2014-08-18, error). A candidate could be r214076, but I don't see why. Unless someone objects I'll close this PR as fixed in a week.
[Bug c++/39934] Union member incorrectly disallowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39934 Paolo Carlini changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org|jason at gcc dot gnu.org, ||paolo.carlini at oracle dot com --- Comment #12 from Paolo Carlini --- Given that with -std=c++11 we now correctly accept this, I'm not sure we should still keep open the c++98 (rather pedantic IMHO) side of the issue. Jason?
[Bug fortran/65469] [4.8/4.9/5 Regression] ICE on bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65469 Dominique d'Humieres changed: What|Removed |Added Status|RESOLVED|NEW Resolution|DUPLICATE |--- --- Comment #4 from Dominique d'Humieres --- Well, I have been too fast. This PR is indeed related to pr59016. However the patch in comment 2 fixes it, but not pr59016 (AFAICT).
[Bug fortran/65469] [4.8/4.9/5 Regression] ICE on bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65469 --- Comment #5 from Dominique d'Humieres --- Comment 4 was based on [Book15] f90/bug% gfc pr65469.f90 pr65469.f90:6:14: type(my_type) :: crap 1 Error: Derived type 'my_type' at (1) is being used before it is defined [Book15] f90/bug% However running the same compilation later gave [Book15] f90/bug% gfc pr65469.f90 pr65469.f90:6:14: type(my_type) :: crap 1 Error: Derived type 'my_type' at (1) is being used before it is defined f951: internal compiler error: Segmentation fault: 11 ... So if this PR is not a duplicate of pr59016, both bugs seem related to p->sym->name being in an unpredictable state.
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #14 from drikosev at otenet dot gr --- Indeed, the new patch in comment 10 does not prevent the ICEs with the the first example bug.f90 (in Description before comment 1).
[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65660 --- Comment #9 from Richard Biener --- Author: rguenth Date: Sat Apr 4 10:47:08 2015 New Revision: 221866 URL: https://gcc.gnu.org/viewcvs?rev=221866&root=gcc&view=rev Log: 2015-04-04 Richard Biener PR tree-optimization/64909 PR tree-optimization/65660 * tree-vectorizer.h (vect_get_known_peeling_cost): Adjust to take a cost vector for scalar iteration cost. (vect_get_single_scalar_iteration_cost): Likewise. * tree-vect-loop.c (vect_get_single_scalar_iteration_cost): Compute the scalar iteration cost into a cost vector. (vect_get_known_peeling_cost): Use the scalar cost vector to account for the cost of the peeled iterations. (vect_estimate_min_profitable_iters): Likewise. * tree-vect-data-refs.c (vect_peeling_hash_get_lowest_cost): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vectorizer.h
[Bug tree-optimization/64909] [4.8 Regression] Missed vectorization with bdver1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64909 --- Comment #14 from Richard Biener --- Author: rguenth Date: Sat Apr 4 10:47:08 2015 New Revision: 221866 URL: https://gcc.gnu.org/viewcvs?rev=221866&root=gcc&view=rev Log: 2015-04-04 Richard Biener PR tree-optimization/64909 PR tree-optimization/65660 * tree-vectorizer.h (vect_get_known_peeling_cost): Adjust to take a cost vector for scalar iteration cost. (vect_get_single_scalar_iteration_cost): Likewise. * tree-vect-loop.c (vect_get_single_scalar_iteration_cost): Compute the scalar iteration cost into a cost vector. (vect_get_known_peeling_cost): Use the scalar cost vector to account for the cost of the peeled iterations. (vect_estimate_min_profitable_iters): Likewise. * tree-vect-data-refs.c (vect_peeling_hash_get_lowest_cost): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vectorizer.h
[Bug fortran/59024] ICE: after printing certain error messages, the compiler seg faults.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59024 --- Comment #3 from Dominique d'Humieres --- > The change of behavior occurred between revisions r214073 (2014-08-17, ICE) > and r214113 (2014-08-18, error). A candidate could be r214076, > but I don't see why. This seems to depend on the mood of my machine: [Book15] f90/bug% /opt/gcc/gcc4.10p-214113/bin/gfortran pr59024.f90 gfortran: warning: couldn't understand kern.osversion '14.1.0 pr59024.f90:6.6: TYPE tc 1 Error: Syntax error in PUBLIC statement at (1) pr59024.f90:7.5: END TYPE tc 1 Error: Expecting END MODULE statement at (1) pr59024.f90:15.12: TYPE(tc) t 1 Error: Derived type 'tc' at (1) is being used before it is defined f951: internal compiler error: Segmentation fault: 11 f951: internal compiler error: Abort trap: 6 gfortran: internal compiler error: Abort trap: 6 (program f951) Abort [Book15] f90/bug% /opt/gcc/gcc4.10p-214113/bin/gfortran pr59024.f90 gfortran: warning: couldn't understand kern.osversion '14.1.0 pr59024.f90:6.6: TYPE tc 1 Error: Syntax error in PUBLIC statement at (1) pr59024.f90:7.5: END TYPE tc 1 Error: Expecting END MODULE statement at (1) pr59024.f90:15.12: TYPE(tc) t 1 Error: Derived type 'tc' at (1) is being used before it is defined pr59024.f90:17.14: END MODULE mtc 1 Error: Procedure 'C_PTR_1' in generic interface 'tc' at (1) is neither function nor subroutine [Book15] f90/bug% /opt/gcc/gcc4.10p-214073/bin/gfortran pr59024.f90 gfortran: warning: couldn't understand kern.osversion '14.1.0 pr59024.f90:6.6: TYPE tc 1 Error: Syntax error in PUBLIC statement at (1) pr59024.f90:7.5: END TYPE tc 1 Error: Expecting END MODULE statement at (1) pr59024.f90:15.12: TYPE(tc) t 1 Error: Derived type 'tc' at (1) is being used before it is defined pr59024.f90:17.14: END MODULE mtc 1 Error: Procedure 'C_PTR_1' in generic interface 'tc' at (1) is neither function nor subroutine So the bisection is not accurate, probably for the same reason as for pr59016.
[Bug rtl-optimization/58033] counterproductive bb-reorder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58033
--- Comment #6 from Oleg Endo ---
Another example on SH:
const char* test (const char* s0, int c, int* rout)
{
int r = 0;
for (int i = 0; i < c; ++i)
r += s0[i];
*rout = r;
return s0;
}
compiled with -O2:
_test:
cmp/pl r5
bf .L4
mov #0,r1
mov r4,r2
.align 2
.L3:
mov.b @r2+,r3
dt r5
bf/s.L3
add r3,r1
.L2:
mov.l r1,@r6
rts
mov r4,r0
.align 1
.L4:
bra .L2
mov #0,r1
compiled with -O2 -fno-reorder-blocks:
_test:
cmp/pl r5
bf/s.L4
mov #0,r1
mov r4,r2
.align 2
.L3:
mov.b @r2+,r3
dt r5
bf/s.L3
add r3,r1
bra .L7
mov.l r1,@r6
.align 1
.L4:
mov.l r1,@r6
.L7:
rts
mov r4,r0
.. which is better, except for the redundant stores. Folding the two stores
gives the minimal code:
_test:
cmp/pl r5
bf/s.L4
mov #0,r1
mov r4,r2
.align 2
.L3:
mov.b @r2+,r3
dt r5
bf/s.L3
add r3,r1
.L4:
mov.l r1,@r6
rts
mov r4,r0
[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65660 --- Comment #10 from rguenther at suse dot de --- On April 3, 2015 8:35:00 PM GMT+02:00, rguenther at suse dot de wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65660 > >--- Comment #8 from rguenther at suse dot de >--- >On April 3, 2015 6:22:48 PM GMT+02:00, "hubicka at gcc dot gnu.org" > wrote: >>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65660 >> >>--- Comment #6 from Jan Hubicka --- >>Performance seems to be back at Apr 2 >>Apr 2, 2015 16:20 UTC >>(Values: Base: 164.gzip: 1562, 175.vpr: 2384, 176.gcc: 2873, 181.mcf: >>3743, >>186.crafty: 2922, 197.parser: 2002, 252.eon: 4144, 255.vortex: 3345, >>256.bzip2: >>2221, 300.twolf: 3269 Peak: , 164.gzip: 1550, 175.vpr: 2402, 176.gcc: >>2838, >>181.mcf: 3810, 186.crafty: 2811, 197.parser: 1918, 252.eon: 4377, >>255.vortex: >>4353, 256.bzip2: 2334, 300.twolf: 3225) >>Apr 2, 2015 07:20 UTC >>(Values: Base: 164.gzip: 1573, 175.vpr: 2144, 176.gcc: 2798, 181.mcf: >>3739, >>186.crafty: 2906, 197.parser: 1990, 252.eon: 3795, 255.vortex: 3100, >>256.bzip2: >>2214, 300.twolf: 3252 Peak: , 164.gzip: 1554, 175.vpr: 2402, 176.gcc: >>2825, >>181.mcf: 3794, 186.crafty: 2804, 197.parser: 1915, 252.eon: 4339, >>255.vortex: >>4350, 256.bzip2: 2344, 300.twolf: 3264) >> >>Not sure what changed in that range > >I patched the tester with some workaround. Now reverted and real fix committed (but that shouldn't fix it due to the back end cost data)
[Bug rtl-optimization/55190] [SH] ivopts causes loop setup bloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55190
--- Comment #6 from Oleg Endo ---
Another example:
const char* test (const char* s0, int c, int* rout)
{
int r = 0;
for (int i = 0; i < c; ++i)
//r += s0[i];
r += *s0++;
*rout = r;
return s0;
}
On SH compiles to:
_test:
cmp/plr5
bf.L4
movr4,r3 // r3 = s0
addr5,r4 // r4 = s0 + c
movr4,r1 // r1 = s0 + c
mov#0,r2
subr3,r1 // r1 = (s0 + c) - s0 = c (d'uh)
.align 2
.L3:
mov.b @r3+,r7
dt r1
bf/s.L3
add r7,r2
.L2:
mov.l r2,@r6
rts
mov r4,r0
.align 1
.L4:
bra .L2
mov #0,r2
[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 #8 from Hans-Peter Nilsson --- (In reply to Hans-Peter Nilsson from comment #5) > (In reply to Martin Liška from comment #3) > > Hello. > > > > I've just sent patch to mailing list: > > https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00108.html > > > > May I ask you for testing if it survives on your target? > > Results aren't final yet, but well past the point of failure, and so far the > regression is gone with no new ones. Thanks. Final: issue fixed with no regressions, thanks!
[Bug debug/57519] DW_TAG_imported_declaration put in wrong class (base class instead of derived class)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57519
--- Comment #9 from Dominique d'Humieres ---
The test succeeds on darwin with the following patch
--- ../_clean/gcc/testsuite/g++.dg/debug/dwarf2/imported-decl-2.C2014-06-04
00:42:23.0 +0200
+++ gcc/testsuite/g++.dg/debug/dwarf2/imported-decl-2.C2015-04-04
13:41:18.0 +0200
@@ -1,5 +1,5 @@
// { dg-do compile }
-// { dg-options "-gdwarf-2 -dA -O0 -fno-merge-debug-strings" }
+// { dg-options "-gdwarf-2 -gno-strict-dwarf -dA -O0 -fno-merge-debug-strings"
}
class
{
[Bug libstdc++/43622] Incomplete C++ library support for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-04 Summary|no C++ typeinfo for |Incomplete C++ library |__float128 |support for __float128 Ever confirmed|0 |1 --- Comment #27 from Marc Glisse --- Renaming since typeinfo is in gcc-5.
[Bug pch/65550] [5 Regression] ICE (segfault) with pch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65550 Markus Trippelsdorf changed: What|Removed |Added Status|WAITING |NEW
[Bug target/65648] [5 Regression] Bad code due to IRA fails to recognize the clobber in parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65648 Vladimir Makarov changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #4 from Vladimir Makarov --- (In reply to Jeffrey A. Law from comment #2) > Well, I think the real issue here is LRA deciding to move insn 12 regardless > of whether or not the MD file gets a scratch register the recommend way or > not. > > Note, the insns below are not consecutive in the .ira dump, had me rather > confused for a few minutes. The insn looks moved as the bug is in new rematerialization sub-pass of LRA. I'll try to fix this until Wednesday.
[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 #3 from Vladimir Makarov --- Author: vmakarov Date: Sat Apr 4 14:35:59 2015 New Revision: 221867 URL: https://gcc.gnu.org/viewcvs?rev=221867&root=gcc&view=rev Log: 2015-04-04 Vladimir Makarov PR target/65647 * lra-int.h (LRA_MAX_REMATERIALIZATION_PASSES): New. Add its value checking. (lra_rematerialization_iter): New. * lra.c (lra): Initialize lra_rematerialization_iter. Stop updating lra_constraint_new_regno_start after switching of inheritance and rematerialization. * lra-remat.c (lra_rematerialization_iter): New. (lra_remat): Add printing pass iteration. Do rematerialization only first LRA_MAX_REMATERIALIZATION_PASSES iterations. 2015-04-04 Vladimir Makarov PR target/65647 * gcc.target/arm/pr65647.c: New. Added: trunk/gcc/testsuite/gcc.target/arm/pr65647.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-int.h trunk/gcc/lra-remat.c trunk/gcc/lra.c trunk/gcc/testsuite/ChangeLog
[Bug target/56997] Incorrect write to packed field when strict-volatile-bitfields enabled on aarch32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997 --- Comment #18 from Bernd Edlinger --- (In reply to Bernd Edlinger from comment #17) > (In reply to Andrew Pinski from comment #16) > > This testcase fails on aarch64 when SLOW_UNALIGNED_ACCESS is true. > > hmm, yes. > > there are targets that define SLOW_UNALIGNED_ACCESS=1, but > they also define STRICT_ALIGNMENT=1 at the same time. > probably this combination is not tested at all. > > does it pass if you use -mstrict-align ? BTW. SLOW_UNALIGNED_ACCESS is no longer used in the strict volatile bitfields code path after r221222.
[Bug c++/59964] gcc segfault on compiling nested parameter pack code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59964 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.9.0, 5.0 Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #1 from Paolo Carlini --- The code is invalid, the ICE is fixed in 4.9.0.
[Bug c/65672] New: type attribute "aligned" can decrease alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65672
Bug ID: 65672
Summary: type attribute "aligned" can decrease alignment
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
https://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html states that
"The aligned attribute can only increase the alignment"
However, on x86_64:
typedef float vec __attribute__((vector_size(16)));
typedef float vecu __attribute__((vector_size(16),aligned(8)));
alignof(vec) says 16 and alignof(vecu) says 8. And indeed,
vec f(vecu*p){
return *p;
}
compiles to movups (while regular loads use movaps), so this behavior is
useful. Assuming it is meant to work and not just an accident, it would be nice
to document this (otherwise it is a wrong code bug).
[Bug target/65535] powerpc64-freebsd build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65535
--- Comment #1 from Andreas Tobler ---
Here a native build seems to succeed, right now in stage three with sources
from today.
[tritium:head/objdir/gcc] andreast% grep -i fbsd_major *
Makefile:tm_defines= LIBC_GLIBC=1 LIBC_UCLIBC=2 LIBC_BIONIC=3 FBSD_MAJOR=11
config.log:tm_defines=' LIBC_GLIBC=1 LIBC_UCLIBC=2 LIBC_BIONIC=3 FBSD_MAJOR=11'
config.status:S["tm_defines"]=" LIBC_GLIBC=1 LIBC_UCLIBC=2 LIBC_BIONIC=3
FBSD_MAJOR=11"
tm.h:#ifndef FBSD_MAJOR
tm.h:# define FBSD_MAJOR 11
FBSD_MAJOR is defined during configure time:
config.gcc:line 666
fbsd_major=`echo ${target} | sed -e 's/.*freebsd//g' | sed -e 's/\..*//g'`
tm_defines="${tm_defines} FBSD_MAJOR=${fbsd_major}"
Can you give me some details about your setup/build?
[Bug target/65535] powerpc64-freebsd build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65535 --- Comment #2 from Andreas Tobler --- Btw, cool bug ID ;) 0x
[Bug target/65535] powerpc64-freebsd build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65535 --- Comment #3 from Andreas Tobler --- Unfortunately the build fails with: /usr/local/bin/ld: libbackend.a(tree-diagnostic.o): bad reloc symbol index (0x1 >= 0x39) for offset 0x3ee6 in section `.debug_info' libbackend.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status /export/devel/net/src/gcc/head/gcc/gcc/c/Make-lang.in:71: recipe for target 'cc1' failed gmake[3]: *** [cc1] Error 1 gmake[3]: Leaving directory '/export/build/src/gcc/head/objdir/gcc' Makefile:: recipe for target 'all-stage3-gcc' failed gmake[2]: *** [all-stage3-gcc] Error 2 But this is independent to your report.
[Bug target/65581] [5 Regression] testsuite lto issue: multiple definition of `main', undefined reference to `WinMain'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65581 --- Comment #15 from Rainer Emrich --- Bug report opened for ld. https://sourceware.org/bugzilla/show_bug.cgi?id=18199
[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65660 --- Comment #11 from Jan Hubicka --- Thanks, 32-bit eon runs improved today, though I am not 100% sure it is ude to vectorization or the unit growth change http://gcc.opensuse.org/SPEC/CINT/sb-frescobaldi.suse.de-head-64-32o-32bit/252_eon_recent_big.png Overall we had better scores on 32bit eon in the past however http://gcc.opensuse.org/SPEC/CINT/sb-frescobaldi.suse.de-head-64-32o-32bit/252_eon_big.png Honza
Re: [Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast
Thanks, 32-bit eon runs improved today, though I am not 100% sure it is ude to vectorization or the unit growth change http://gcc.opensuse.org/SPEC/CINT/sb-frescobaldi.suse.de-head-64-32o-32bit/252_eon_recent_big.png Overall we had better scores on 32bit eon in the past however http://gcc.opensuse.org/SPEC/CINT/sb-frescobaldi.suse.de-head-64-32o-32bit/252_eon_big.png Honza
[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
.file"1.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
.ident"GCC: (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
.file"1.c"
.globlfoo
.bss
.align 16
.typefoo, @object
.sizefoo, 16
foo:
.zero16
.ident"GCC: (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.
