[Bug ipa/61885] [4.10 Regression] ICE: in types_same_for_odr, at ipa-devirt.c:383 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61885 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Markus Trippelsdorf --- Fixed by r213232.
[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 --- Comment #29 from Jan Hubicka --- Created attachment 33209 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33209&action=edit patch I am testing Sorry for taking so long on this issue - I had busy time and there is no really good answer to this problem. C++ require constant variables to be folded, ELF interposition interpreted in full generality prevents folding of many symbols. We behave in C++ way for years and I think it should stay a default, so I think we can special case the user specified WEAK attribute - i.e. do not give up on PIC exported symbols nor C++ COMDATs as we already special case COMDAT. I hope this won't break non-ELF targets, like AIX - will give it a try.
[Bug c++/61959] [4.8/4.9/4.10 Regression] ICE: in tree_to_uhwi, at tree.h:3657 when building Mozilla code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61959
Richard Biener changed:
What|Removed |Added
Component|middle-end |c++
--- Comment #6 from Richard Biener ---
The constructor is invalid:
(gdb) p debug_generic_expr (exp)
{.D.2102={.x={.D.2071={.value=1}}, .y={.D.2071={.value=1}}}, .(struct A *) this
+ 8={}}
the element index has to be a FIELD_DECL - 'this + 8' is not allowed here.
C++ frontend issue.
[Bug tree-optimization/61938] Vectorization not happening .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61938 --- Comment #5 from Richard Biener --- The test from comment #3 has exactly the same issue - the store to result[k] cannot be vectorized in any meaningful way.
[Bug target/61330] [4.10 Regression] Thumb ICE for case 920507-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61330 --- Comment #6 from wangzheyu --- Posted a possible fix for this bug: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01938.html
[Bug middle-end/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61950 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-07-30 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Ok, sparc is big-endian. I suppose my added big-endian testcases pass. I'll see if a cross f951 to sparc-sun-solaris2.11 reveals anything.
[Bug fortran/61960] New: internal compiler error: in gfc_conv_component_ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61960 Bug ID: 61960 Summary: internal compiler error: in gfc_conv_component_ref Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: geertjan.bex at uhasselt dot be Created attachment 33210 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33210&action=edit directory containing source to reproduce, and output of compiler When compiling, the compiler crashes with the following error: internal compiler error: in gfc_conv_component_ref, at fortran/trans-expr.c:1574 Compiler command & options: gfortran -v -save-temps -O2 -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -g -Wall -Wextra -c data_func_mod.f90 refactored_func.f90 Detail and source code can be found in the file 'output.txt' that is included in the gzipped tar file. The OS is: Linux version 2.6.32-358.el6.x86_64 (mockbu...@x86-022.build.eng.bos.redhat.com) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) ) #1 SMP Tue Jan 29 11:47:41 EST 2013 However, the crash can be reproduced with GCC 4.7.2 on the same system, and 4.8.2-19ubuntu1 on: Linux version 3.13.0-32-generic (buildd@roseapple) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #57-Ubuntu SMP Tue Jul 15 03:51:12 UTC 2014 Best, -gjb-
[Bug middle-end/61949] [4.10 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-07-30 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- it's odd that stage2 is not affected... can you provide preprocessed source of libiberty/md5.c as compiled for the host?
[Bug middle-end/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61950
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #2 from Richard Biener ---
The gimple for the cited line looks good to me:
addarray1 (&class.25, &class.26);
class.26 ={v} {CLOBBER};
class.25 ={v} {CLOBBER};
class.30._data = pt_43->p._data;
SR.179_160 = MEM[(struct object_array_pointer *)pt_43];
SR.181_102 = MEM[(struct object_array_pointer *)pt_43 + 12B];
SR.182_94 = MEM[(struct object_array_pointer *)pt_43 + 16B];
_53 = pt_43->p._vptr;
_57 = SR.182_94 * SR.181_102;
_58 = -_57;
_60 = _53->_hash;
switch (_60) , case 37104555: >
:
_243 = MEM[(struct t[0:] *)SR.179_160][0].i;
if (_243 != 1)
goto ;
else
goto ;
:
_62 = SR.182_94 + 1;
_63 = _62 * SR.181_102;
_64 = _63 - _57;
_65 = MEM[(struct t[0:] *)SR.179_160][_64].i;
if (_65 != 2)
goto ;
else
goto ();
we have constant-folded from the initializer of A.28 = [1, 2].
For the testcase (at -O1) we never call native_encode_expr with off != -1
so the only difference can be that we call native_encode_expr more
often or that the code-path for off == -1 changed (which it wasn't supposed
to).
Btw all calls to native_encode_expr are via fold_view_convert_expr ultimately
called from the frontend and all return NULL and thus fail.
So I wonder whether it rather is libgfortran that is miscompiled? Can you
check running the testcases against an older version?
[Bug c++/61961] New: New warning when initializer-list constructor chosen for uniform init that doesn't mean to use initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61961
Bug ID: 61961
Summary: New warning when initializer-list constructor chosen
for uniform init that doesn't mean to use
initializer_list
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
#include
int main()
{
std::string s{1ul, 'a'};
}
It would be nice to get a warning here that the initializer-list constructor
was chosen rather than the string(size_type, value_type) constructor.
The semantics I suggest are to warn when:
* an initializer-list constructor is selected by overload resolution
* the elements of the braced-init-list are not all the same type
* another (non-initializer-list) constructor is viable
So no warnings for:
std::string{'a', 'b'} // elements are same type
std::string{'0'+(x%10), '0'+(y%10)} // elements are same type
std::string{'a', 'b', 'c', 'd', 0} // no other viable constructor
std::string{1ul, '0'+(x%10)}// use char('0'+(x%10)) to get warning
but warnings for:
std::string(1ul, 'a'} // motivating case
std::string{'a', 0} // use '\0' to suppress warning
[Bug other/61962] New: GCC seems to enter an infinite loop when compiling the above code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61962
Bug ID: 61962
Summary: GCC seems to enter an infinite loop when compiling the
above code.
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: nick.tomlinson at arm dot com
Created attachment 33211
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33211&action=edit
A minimal reproducer
Steps to reproduce
- Build with: g++ -fcilkplus -c arrayinf.cpp
- Wait for 60 seconds.
- Observe that g++ is still running.
What I expected to happen
- g++ should terminate, with an object file having been produces.
What actually happened
- After the 60 seconds, g++ is still running, and consuming an entire core.
Environment
I have tried this with:
- My system GCC (g++, version 4.9.1)
- A native build of GCC (${GCC_TRUNK}/bin/g++, revision r213234)
${GCC_TRUNK}/bin/g++ is a native build of GCC, with the following specified
to the configure script:
./configure --prefix=${GCC_TRUNK} \
--enable-languages=c,c++,fortran --disable-sjlj-exceptions
And make invoked as: make CXXFLAGS="-g3 -O0" -j9
$ uname -a
Linux squamata 3.15.7-1-ARCH #1 SMP PREEMPT Mon Jul 28 20:06:17 CEST 2014
x86_64 GNU/Linux
$ g++ --version
g++ (GCC) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ${GCC_TRUNK}/bin/g++ --version
g++ (GCC) 4.10.0 20140730 (experimental)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Possibly related bugs
- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59053
Also goes into a loop, though its reproducer is a lot longer, so its hard
to tell if it's for the same reason.
[Bug other/59053] cilkplus branch compiler loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59053
Nick Tomlinson changed:
What|Removed |Added
CC||nick.tomlinson at arm dot com
--- Comment #5 from Nick Tomlinson ---
Possibly related to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61962
The reproducer attached to that bug (see below) also enters an infinite loop
(build with g++ -fcilkplus -c arrayinf.cpp):
struct FloatStruct
{
float *f;
};
/* Either SRC or DST must be a struct, otherwise the bug does not occur. */
void f (FloatStruct *dst, float *src, unsigned int length)
{
dst->f[0:length] = src[0:length];
}
[Bug middle-end/57541] [Cilkplus]: internal compiler error: in gimplify_expr, at gimplify.c:7809
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57541
Nick Tomlinson changed:
What|Removed |Added
CC||nick.tomlinson at arm dot com
--- Comment #12 from Nick Tomlinson ---
https://gcc.gnu.org/bugzilla/attachment.cgi?id=30285 still produces an ICE for
me:
I have tried this with:
- My system GCC (g++, version 4.9.1)
- A native build of GCC (${GCC_TRUNK}/bin/g++, revision r213234)
${GCC_TRUNK}/bin/g++ is a native build of GCC, with the following specified
to the configure script:
./configure --prefix=${GCC_TRUNK} \
--enable-languages=c,c++,fortran --disable-sjlj-exceptions
And make invoked as: make CXXFLAGS="-g3 -O0" -j9
$ uname -a
Linux squamata 3.15.7-1-ARCH #1 SMP PREEMPT Mon Jul 28 20:06:17 CEST 2014
x86_64 GNU/Linux
$ g++ --version
g++ (GCC) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ${GCC_TRUNK}/bin/g++ --version
g++ (GCC) 4.10.0 20140730 (experimental)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug middle-end/57541] [Cilkplus]: internal compiler error: in gimplify_expr, at gimplify.c:7809
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57541
--- Comment #13 from Nick Tomlinson ---
(In reply to Nick Tomlinson from comment #12)
> https://gcc.gnu.org/bugzilla/attachment.cgi?id=30285 still produces an ICE
> for me:
>
> I have tried this with:
>- My system GCC (g++, version 4.9.1)
>- A native build of GCC (${GCC_TRUNK}/bin/g++, revision r213234)
>
> ${GCC_TRUNK}/bin/g++ is a native build of GCC, with the following specified
> to the configure script:
> ./configure --prefix=${GCC_TRUNK} \
> --enable-languages=c,c++,fortran --disable-sjlj-exceptions
> And make invoked as: make CXXFLAGS="-g3 -O0" -j9
>
> $ uname -a
> Linux squamata 3.15.7-1-ARCH #1 SMP PREEMPT Mon Jul 28 20:06:17 CEST 2014
> x86_64 GNU/Linux
>
> $ g++ --version
> g++ (GCC) 4.9.1
> Copyright (C) 2014 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> $ ${GCC_TRUNK}/bin/g++ --version
> g++ (GCC) 4.10.0 20140730 (experimental)
> Copyright (C) 2014 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
test.cpp: In function 'int main()':
test.cpp:4:53: internal compiler error: in gimplify_expr, at gimplify.c:8389
int a = __sec_reduce_add (__sec_reduce_add (A[:]));
^
0x9bc36b gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
/home/nicholas/GCCCilk/bug/native/gcc-4.9.0/gcc/gimplify.c:8389
0x9c378f gimplify_call_expr
/home/nicholas/GCCCilk/bug/native/gcc-4.9.0/gcc/gimplify.c:2432
0x9b9a2b gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
/home/nicholas/GCCCilk/bug/native/gcc-4.9.0/gcc/gimplify.c:7644
0x9c378f gimplify_call_expr
/home/nicholas/GCCCilk/bug/native/gcc-4.9.0/gcc/gimplify.c:2432
0x9b9a2b gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
/home/nicholas/GCCCilk/bug/native/gcc-4.9.0/gcc/gimplify.c:7644
0x9b8270 gimplify_modify_expr
/home/nicholas/GCCCilk/bug/native/gcc-4.9.0/gcc/gimplify.c:4571
0x9b98ef gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
/home/nicholas/GCCCilk/bug/native/gcc-4.9.0/gcc/gimplify.c:7673
0x9be136 gimplify_stmt(tree_node**, gimple_statement_base**)
/home/nicholas/GCCCilk/bug/native/gcc-4.9.0/gcc/gimplify.c:5417
0x9b9aca gimplify_cleanup_point_expr
/home/nicholas/GCCCilk/bug/native/gcc-4.9.0/gcc/gimplify.c:5193
0x9b9aca gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
/home/nicholas/GCCCilk/bug/native/gcc-4.9.0/gcc/gimplify.c:8036
0x9be136 gimplify_stmt(tree_node**, gimple_statement_base**)
/home/nicholas/GCCCilk/bug/native/gcc-4.9.0/gcc/gimplify.c:5417
0x9b9d2b gimplify_statement_list
/home/nicholas/GCCCilk/bug/native/gcc-4.9.0/gcc/gimplify.c:1451
0x9b9d2b gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
/home/nicholas/GCCCilk/bug/native/gcc-4.9.0/gcc/gimplify.c:8088
0x9be136 gimplify_stmt(tree_node**, gimple_statement_base**)
/home/nicholas/GCCCilk/bug/native/gcc-4.9.0/gcc/gimplify.c:5417
0x9befe5 gimplify_bind_expr
/home/nicholas/GCCCilk/bug/native/gcc-4.9.0/gcc/gimplify.c:1100
0x9b9a09 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
/home/nicholas/GCCCilk/bug/native/gcc-4.9.0/gcc/gimplify.c:7870
0x9be136 gimplify_stmt(tree_node**, gimple_statement_base**)
/home/nicholas/GCCCilk/bug/native/gcc-4.9.0/gcc/gimplify.c:5417
0x9b9d2b gimplify_statement_list
/home/nicholas/GCCCilk/bug/native/gcc-4.9.0/gcc/gimplify.c:1451
0x9b9d2b gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
/home/nicholas/GCCCilk/bug/native/gcc-4.9.0/gcc/gimplify.c:8088
0x9be136 gimplify_stmt(tree_node**, gimple_statement_base**)
/home/nicholas/GCCCilk/bug/native/gcc-4.9.0/gcc/gimplify.c:5417
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 target/52268] native tls support should be added for darwin11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52268 --- Comment #12 from Eric Gallager --- (In reply to Jeremy Huddleston Sequoia from comment #10) > Ah, gotcha. In that case, please retitle as well to indicate such. Prior to > gcc-4.5, even support via emutls was not available on darwin, so some people > in #macports thought that's what this ticket was referring to. Thanks. (that was me in https://trac.macports.org/ticket/44062#comment:59 for reference... anyways, thanks for clearing this up!)
[Bug other/61963] New: CilkPlus Array Notation ICE in build_array_notation_ref on malformed function arguments.
-prefix=${GCC_TRUNK} \
--enable-languages=c,c++,fortran --disable-sjlj-exceptions
And make invoked as: make CXXFLAGS="-g3 -O0" -j9
$ uname -a
Linux squamata 3.15.7-1-ARCH #1 SMP PREEMPT Mon Jul 28 20:06:17 CEST 2014
x86_64 GNU/Linux
$ g++ --version
g++ (GCC) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ${GCC_TRUNK}/bin/g++ --version
g++ (GCC) 4.10.0 20140730 (experimental)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug middle-end/61949] [4.10 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Richard Biener --- > it's odd that stage2 is not affected... can you provide preprocessed source I lied: if you generate the .gch file with the stage2 cc1, both stage2 and 3 cc1 SEGV the same way. > of libiberty/md5.c as compiled for the host? Attached. Rainer
[Bug middle-end/61949] [4.10 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 --- Comment #3 from Rainer Orth --- Created attachment 33213 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33213&action=edit preprocessed libiberty/md5.c
[Bug middle-end/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61950 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from Richard Biener --- [...] > So I wonder whether it rather is libgfortran that is miscompiled? Can you > check running the testcases against an older version? After I initially saw the failures during a regular bootstrap, I tried with the libgfortran.so.3 bundled with Solaris 11 (from gcc 4.5 or gcc 4.8), and the testcase fails just the same. Rainer
[Bug tree-optimization/61964] New: [4.8 regression] krb5 database propagation enters infinite loop; reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964
Bug ID: 61964
Summary: [4.8 regression] krb5 database propagation enters
infinite loop; reduced test case
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: andersk at mit dot edu
Kerberos is miscompiled by gcc-4.8. The impact is detailed at
https://bugs.launchpad.net/bugs/1347147, but here is a reduced test case. The
expected return is 0, but when compiled with gcc-4.8 -O2, it returns 1.
$ cat bug.c
struct node { struct node *next, *prev; } node;
struct head { struct node *first; } heads[5];
int k = 2;
struct head *head = &heads[2];
int main()
{
node.prev = (void *)head;
head->first = &node;
struct node *n = head->first;
struct head *h = &heads[k];
if (n->prev == (void *)h)
h->first = n->next;
else
n->prev->next = n->next;
n->next = h->first;
return n->next == &node;
}
$ gcc-4.7 -Wall -O2 bug.c -o bug; ./bug; echo $?
0
$ gcc-4.8 -Wall -O2 bug.c -o bug; ./bug; echo $?
1
$ gcc-4.9 -Wall -O2 bug.c -o bug; ./bug; echo $?
0
$ dpkg -l gcc-4.7 gcc-4.8 gcc-4.9
[…]
ii gcc-4.7 4.7.4-2ubuntu1 amd64 GNU C compiler
ii gcc-4.8 4.8.3-6ubuntu1 amd64 GNU C compiler
ii gcc-4.9 4.9.1-3ubuntu2 amd64 GNU C compiler
I bisected the point where the problem disappeared between 4.8 and 4.9 at
r202525. However, I don’t understand why. I’m scared by the fact that r202525
was intended to fix a “missed-optimization” bug (bug 58404).
[Bug tree-optimization/61964] [4.8 regression] krb5 database propagation enters infinite loop; reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964 Richard Biener changed: What|Removed |Added Known to work|4.7.4, 4.9.0| Known to fail|4.8.3 | --- Comment #1 from Richard Biener --- The testcase is violating strict-aliasing rules as you access a struct head as struct node here: if (n->prev == (void *)h) h->first = n->next; else n->prev->next = n->next; as n->prev points to &heads[0] while h is &heads[2] (an out-of-bound pointer). So n->prev is a struct head and you access a next field of a struct node of it. Changing k to 0 makes the testcase pass (now you don't run into the bogus path).
[Bug c++/61639] GCC 4.7.4 can't longer compile clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61639 John Feltz changed: What|Removed |Added CC||jfeltz at gmail dot com --- Comment #4 from John Feltz --- This bug needs to be redefined as it also occurs with gcc-4.9.1 as well, but may not actually be a fault of gcc (on a Debian squeeze system with compiled gcc-4.9.1).
[Bug c/61965] New: [gcc-4.8.2] ICE:in compute_affine_dependence (at tree-data-ref.c:4170)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61965
Bug ID: 61965
Summary: [gcc-4.8.2] ICE:in compute_affine_dependence (at
tree-data-ref.c:4170)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sabrinadfs at gmail dot com
Created attachment 33214
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33214&action=edit
test log
x86_64-unknown-linux-gnu
GCC version: 4.8.2
Running the test 20090922-1.c from gcc.dg package GCC throw an ICE with these
options:
-Wno-format/-fno-sanitize=address/-fno-align-functions/-fno-align-jumps/-fno-align-loops/-fno-align-labels/-fno-ipa-cp/-fno-ipa-pure-const/-fno-ipa-reference/-fno-tree-pta//-fno-selective-scheduling/-fno-selective-scheduling2/-fno-reorder-blocks-and-partition/-fcheck-data-deps/-fno-unswitch-loops/-fno-predictive-commoning/-fno-tree-vectorize/-fno-tree-partial-pre/-fno-strict-aliasing/-fno-syntax-only
I also managed to reproduce the ICE out of DejaGnu just by running this line:
/home/sabrina/gcc/objdir/gcc/xgcc -B/home/sabrina/gcc/objdir/gcc/
/home/sabrina/gcc/gcc-4.8.2/gcc/testsuite/gcc.dg/20090922-1.c
-fno-diagnostics-show-caret -O2 -g -funroll-loops -std=gnu99 -S -Wno-format
-fno-sanitize=address -fno-align-functions -fno-align-jumps -fno-align-loops
-fno-align-labels -fno-ipa-cp -fno-ipa-pure-const -fno-ipa-reference
-fno-tree-pta -fno-selective-scheduling -fno-selective-scheduling2
-fno-reorder-blocks-and-partition -fcheck-data-deps -fno-unswitch-loops
-fno-predictive-commoning -fno-tree-vectorize -fno-tree-partial-pre
-fno-strict-aliasing -fno-syntax-only -o 20090922-1.c
Here is the testcode (../gcc/testsuite/gcc.dg/20090922-1.c):
/* { dg-do compile } */
/* { dg-options "-O2 -g -funroll-loops -std=gnu99" } */
struct S
{
unsigned long s1;
int **s2;
};
struct T
{
unsigned long t1, t2;
};
struct U
{
int u1, u2;
unsigned long u3;
};
struct V
{
int v1, v3;
struct T *v2;
struct U *v4;
};
struct W
{
int w1;
struct V **w2;
};
struct S *foo1 (void);
int *foo2 (void);
void
test (struct W *w)
{
for (int i = 0; i < w->w1; i++)
{
struct V *v = w->w2[i];
struct S *t = foo1 ();
if (!t)
for (int j; j < v->v1;)
{
struct T *q = &v->v2[j];
t += (q->t2 - q->t1) * 45000L;
}
for (; v->v3;)
{
struct U *v4 = (struct U *) &v->v4;
if (v4->u1 && v4->u2 >= 0 && v4->u2)
{
int *s = foo2 ();
if (!s)
for (int k = 0; k <= v4->u2; k++)
{
struct T *q = &v->v2[k];
if (k == v4->u2)
v4->u3 += (q->t1) * 100;
}
t->s2[t->s1] = s;
}
}
int *s = foo2 ();
if (!t)
t->s2[t->s1] = s;
}
}
Here is the output:
(Number of distance vectors differ: Banerjee has 2, Omega has 1.
Banerjee dist vectors:
0
1
Omega dist vectors:
0
data dependence relation:
(Data Dep:
#(Data Ref:
# bb: 17
# stmt: _47 = MEM[(struct U *)v_19 + 16B].u3;
# ref: MEM[(struct U *)v_19 + 16B].u3;
# base_object: MEM[(struct U *)v_19 + 16B];
# Access function 0: 64
#)
#(Data Ref:
# bb: 17
# stmt: MEM[(struct U *)v_19 + 16B].u3 = _50;
# ref: MEM[(struct U *)v_19 + 16B].u3;
# base_object: MEM[(struct U *)v_19 + 16B];
# Access function 0: 64
#)
access_fn_A: 64
access_fn_B: 64
(subscript
iterations_that_access_an_element_twice_in_A: [0]
last_conflict: scev_not_known
iterations_that_access_an_element_twice_in_B: [0]
last_conflict: scev_not_known
(Subscript distance: 0 ))
inner loop index: 0
loop nest: (4 )
distance_vector: 0
direction_vector: =
)
)
/home/sabrina/gcc/gcc-4.8.2/gcc/testsuite/gcc.dg/20090922-1.c: In function
‘test’:
/home/sabrina/gcc/gcc-4.8.2/gcc/testsuite/gcc.dg/20090922-1.c:33:1: internal
compiler error: in compute_affine_dependence, at tree-data-ref.c:4170
0xbcc0d2 compute_affine_dependence(data_dependence_relation*, loop*)
.././../gcc-4.8.2/gcc/tree-data-ref.c:4169
0xbce98d compute_all_dependences(vec,
vec*, vec,
bool)
.././../gcc-4.8.2/gcc/tree-data-ref.c:4241
0xbcef83 compute_data_dependences_for_loop(loop*, bool, vec*, vec*,
vec*)
.././../gcc-4.8.2/gcc/tree-data-ref.c:4531
0xbcf18f analyze_all_data_dependences
.././../gcc-4.8.2/gcc/tree-data-ref.c:4639
0xbcf18f tree_check_data_deps()
.././../gcc-4.8.2/gcc/tree-data-ref.c:4687
0x8b62a7 check_data_deps
.././../gcc-4.8.2/gcc/tree-ssa-loop.c:330
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/61949] [4.10 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949
Richard Biener changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
Component|middle-end |target
--- Comment #4 from Richard Biener ---
Ok, I can reproduce similar code it on i?86-linux with -msse2
-fno-omit-frame-pointer. Does Solaris 10 properly align the stack for
stack-realignment to work? That is, does
void *
md5_read_ctx (const struct md5_ctx *ctx, void *resbuf)
{
md5_uint32 buffer[4] __attribute__((aligned(16)));
buffer[0] = SWAP (ctx->A);
buffer[1] = SWAP (ctx->B);
buffer[2] = SWAP (ctx->C);
buffer[3] = SWAP (ctx->D);
memcpy (resbuf, buffer, 16);
return resbuf;
}
work reliably to align buffer to 16 bytes? On x86_64-linux with -m32 I get
md5_read_ctx:
.LFB3:
.cfi_startproc
pushl %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl%esp, %ebp
.cfi_def_cfa_register 5
subl$24, %esp
movl8(%ebp), %edx
movl12(%ebp), %eax
movl(%edx), %ecx
movl%ecx, -24(%ebp)
movl4(%edx), %ecx
movl%ecx, -20(%ebp)
movl8(%edx), %ecx
movl12(%edx), %edx
movl%ecx, -16(%ebp)
movl%edx, -12(%ebp)
movaps -24(%ebp), %xmm0
movups %xmm0, (%eax)
leave
.cfi_restore 5
.cfi_def_cfa 4, 4
ret
which should be aligned if the incoming stack is aligned to 16 bytes.
Ok interestingly we do build an unaligned TImode load from the builtin
folder but then expansion concludes that the load is aligned after all
because the VAR_DECL has 16byte alignment:
Breakpoint 6, expand_expr_real_1 (exp=,
target=0x76e003d8, tmode=TImode, modifier=EXPAND_NORMAL, alt_rtl=0x0,
inner_reference_p=false) at /space/rguenther/src/svn/trunk/gcc/expr.c:9730
9730if (mem_ref_refers_to_non_mem_p (exp))
unit size
align 32 symtab 0 alias set -1 canonical type 0x76c50930 precision
128 min max >
arg 0
public unsigned SI
size
unit size
align 32 symtab 0 alias set -1 canonical type 0x76df4348>
arg 0
used BLK file /space/rguenther/src/svn/trunk/libiberty/md5.c line
68 col 14 size unit size
align 128 context
(mem/c:BLK (plus:SI (reg/f:SI 78 virtual-stack-vars)
(const_int -16 [0xfff0])) [3 buffer+0 S16 A128])>
/space/rguenther/src/svn/trunk/libiberty/md5.c:75:19>
arg 1
constant 0>>
if that's the same on solaris10/x86 then for some reason expansion cannot
align that stack local as it says it is aligned. You can also see this
from the expansion of the buffer[0] store:
(insn 8 7 0 (set (mem/c:SI (plus:SI (reg/f:SI 78 virtual-stack-vars)
(const_int -16 [0xfff0])) [3 buffer+0 S4 A128])
(reg:SI 91)) /space/rguenther/src/svn/trunk/libiberty/md5.c:70 -1
(nil))
see how it says A128.
So eventually the backend is wrong in handing out such large alignment
to stack locals or the code that is supposed to dynamically re-align
the stack doesn't trigger or doesn't work.
Please do some more digging on the Solaris side. Target issue, stack
alignment related (HJ?)
[Bug target/61949] [4.10 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949
--- Comment #5 from Richard Biener ---
Reduced testcase, compile with -m32 -msse -O2 -fno-omit-frame-pointer
(works on a x86_64-linux host, no 32bit host available right now):
struct md5_ctx
{
unsigned int A;
unsigned int B;
unsigned int C;
unsigned int D;
unsigned int total[2];
unsigned int buflen;
char buffer[128] __attribute__ ((__aligned__ (__alignof__ (unsigned int;
};
void * __attribute__((noinline,noclone))
md5_read_ctx (const struct md5_ctx *ctx, void *resbuf)
{
unsigned int buffer[4];
buffer[0] = (ctx->A);
buffer[1] = (ctx->B);
buffer[2] = (ctx->C);
buffer[3] = (ctx->D);
__builtin_memcpy (resbuf, buffer, 16);
return resbuf;
}
int main()
{
char resbuf[16];
struct md5_ctx c;
md5_read_ctx (&c, resbuf);
return 0;
}
Does this testcase fail on Solaris 10?
[Bug tree-optimization/61964] [4.8 regression] krb5 database propagation enters infinite loop; reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964 ghudson at mit dot edu changed: What|Removed |Added CC||ghudson at mit dot edu --- Comment #2 from ghudson at mit dot edu --- How do you conclude that n->prev points to &heads[0]? node.prev receives the value (void *)head, where head is initialized to &heads[2]. I cannot see any uses of &heads[0] in the test program.
[Bug target/61949] [4.10 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 --- Comment #6 from H.J. Lu --- How is GCC configured for i386-pc-solaris2.10? i386 won't use SSE instructions by default.
[Bug c/59855] Support sparse-style __attribute__((designated_init)) on structures, requiring designated initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59855 --- Comment #3 from Tom Tromey --- Author: tromey Date: Wed Jul 30 15:02:59 2014 New Revision: 213293 URL: https://gcc.gnu.org/viewcvs?rev=213293&root=gcc&view=rev Log: 2014-07-30 Tom Tromey PR c/59855 * doc/invoke.texi (Warning Options): Document -Wdesignated-init. * doc/extend.texi (Type Attributes): Document designated_init attribute. 2014-07-30 Tom Tromey PR c/59855 * c.opt (Wdesignated-init): New option. * c-common.c (c_common_attribute_table): Add "designated_init". (handle_designated_init): New function. 2014-07-30 Tom Tromey * c-typeck.c (struct constructor_stack) : New field. (really_start_incremental_init, push_init_level): Initialize designator_depth. (pop_init_level): Set global designator_depth. (process_init_element): Check for designated_init attribute. Added: trunk/gcc/testsuite/gcc.dg/Wdesignated-init.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c-family/c.opt trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/doc/extend.texi trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug c/59855] Support sparse-style __attribute__((designated_init)) on structures, requiring designated initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59855 Tom Tromey changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #4 from Tom Tromey --- Implemented on trunk.
[Bug c++/61966] New: [C++11] std::terminate called after throwing exception from destructor [g++] [4.8.2] [4.9.1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61966
Bug ID: 61966
Summary: [C++11] std::terminate called after throwing exception
from destructor [g++] [4.8.2] [4.9.1]
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: formenel at gmail dot com
Created attachment 33215
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33215&action=edit
ii file - 4.8.2
According to C++ standard 15.2.2 - It's allowed to throw exception from class
destructor. If exception from destructor thrown during stack unwinding
std::terminate is called, otherwise exception should be handled normally
Problem exists only with -std=c++11, version 4.6.0 behaves ok
Here is code which generates call to std::terminate though standard allows it:
class Exc : public std::exception {
public:
virtual const char* what() const throw()
{ return "test exception"; }
};
class Test {
public:
Test()
{ }
~Test()
{
throw Exc();
}
};
int main()
{
try {
{
Test();
}
}
catch (Exc& exc)
{
std::cout << exc.what() << std::endl;
}
}
Compile line:
g++ -v -save-temps -Wall -Wextra -std=c++11 exc-terminate.cc
g++ 4.8.2 output ---
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=c++11'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/4.8/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE exc-terminate.cc -mtune=generic -march=x86-64
-std=c++11 -Wall -Wextra -fpch-preprocess -fstack-protector -Wformat
-Wformat-security -o exc-terminate.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/4.8"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.8
/usr/include/x86_64-linux-gnu/c++/4.8
/usr/include/c++/4.8/backward
/usr/lib/gcc/x86_64-linux-gnu/4.8/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=c++11'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/4.8/cc1plus -fpreprocessed exc-terminate.ii
-quiet -dumpbase exc-terminate.cc -mtune=generic -march=x86-64 -auxbase
exc-terminate -Wall -Wextra -std=c++11 -version -fstack-protector -Wformat
-Wformat-security -o exc-terminate.s
GNU C++ (Ubuntu 4.8.2-19ubuntu1) version 4.8.2 (x86_64-linux-gnu)
compiled by GNU C version 4.8.2, GMP version 5.1.3, MPFR version 3.1.2-p3,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Ubuntu 4.8.2-19ubuntu1) version 4.8.2 (x86_64-linux-gnu)
compiled by GNU C version 4.8.2, GMP version 5.1.3, MPFR version 3.1.2-p3,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 26a7c0bd346d04102f6aea776e05
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=c++11'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
as -v --64 -o exc-terminate.o exc-terminate.s
GNU assembler version 2.24 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.24
COMPILER_PATH=/usr/lib/gcc/x
[Bug c++/61966] [C++11] std::terminate called after throwing exception from destructor [g++] [4.8.2] [4.9.1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61966 --- Comment #1 from Sergey Murzin --- Same problem exists in 4.9.1
[Bug c++/61966] [C++11] std::terminate called after throwing exception from destructor [g++] [4.8.2] [4.9.1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61966 --- Comment #2 from Sergey Murzin --- Problem doesn't exist in 4.6.0 and 4.7.2
[Bug ada/61954] Ada fails to properly pass pointer arguments on x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61954 --- Comment #3 from H.J. Lu --- s-os_lib.adb has function Write (FD : File_Descriptor; A : System.Address; N : Integer) return Integer is begin return Integer (System.CRTL.write (System.CRTL.int (FD), System.CRTL.chars (A), System.CRTL.size_t (N))); end Write; It is compiled into jmpwrite 'A' should be a pointer, not integer.
[Bug c++/61966] [C++11] std::terminate called after throwing exception from destructor [g++] [4.8.2] [4.9.1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61966 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jonathan Wakely --- (In reply to Sergey Murzin from comment #0) > Created attachment 33215 [details] > ii file - 4.8.2 > > According to C++ standard 15.2.2 - It's allowed to throw exception from > class destructor. In C++11 destructors have noexcept(true) by default, so they're allowed to throw, but it will call std::terminate. If you want to throw from destructors they need to have noexcept(false)
[Bug c/61965] [gcc-4.8.2] ICE:in compute_affine_dependence (at tree-data-ref.c:4170)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61965
--- Comment #1 from Sabrina Souto ---
It happened again, now for this test: ../gcc/testsuite/gcc.dg/pr39794.c
Hera is the line executed:
/home/sabrina/gcc/objdir/gcc/xgcc -B/home/sabrina/gcc/objdir/gcc/
/home/sabrina/gcc/gcc-4.8.2/gcc/testsuite/gcc.dg/pr39794.c
-fno-diagnostics-show-caret -O2 -funroll-loops -fcheck-data-deps -o
./pr39794.c
Here is the testcode (../gcc/testsuite/gcc.dg/pr39794.c):
/* PR rtl-optimization/39794 */
/* { dg-do run } */
/* { dg-options "-O2 -funroll-loops" } */
extern void abort ();
void
foo (int *a, int n)
{
int i;
for (i = 0; i < n; i++)
{
a[i] *= 2;
a[i + 1] = a[i - 1] + a[i - 2];
}
}
int a[16];
int ref[16] = { 0, 1, 4, 2, 10, 12, 24, 44,
72, 136, 232, 416, 736, 1296, 2304, 2032 };
int
main ()
{
int i;
for (i = 0; i < 16; i++)
a[i] = i;
foo (a + 2, 16 - 3);
for (i = 0; i < 16; i++)
if (ref[i] != a[i])
abort ();
return 0;
}
Here is the output:
(Number of distance vectors differ: Banerjee has 1, Omega has 0.
Banerjee dist vectors:
1
Omega dist vectors:
data dependence relation:
(Data Dep:
#(Data Ref:
# bb: 5
# stmt: _9 = *_8;
# ref: *_8;
# base_object: *a_5(D);
# Access function 0: {0B, +, 4}_1
#)
#(Data Ref:
# bb: 5
# stmt: *_14 = _21;
# ref: *_14;
# base_object: *a_5(D);
# Access function 0: {4B, +, 4}_1
#)
access_fn_A: {0B, +, 4}_1
access_fn_B: {4B, +, 4}_1
(subscript
iterations_that_access_an_element_twice_in_A: [1 + 1 * x_1]
last_conflict: 2147483646
iterations_that_access_an_element_twice_in_B: [0 + 1 * x_1]
last_conflict: 2147483646
(Subscript distance: 1 ))
inner loop index: 0
loop nest: (1 )
)
)
/home/sabrina/gcc/gcc-4.8.2/gcc/testsuite/gcc.dg/pr39794.c: In function ‘foo’:
/home/sabrina/gcc/gcc-4.8.2/gcc/testsuite/gcc.dg/pr39794.c:8:1: internal
compiler error: in compute_affine_dependence, at tree-data-ref.c:4170
0xbcc0d2 compute_affine_dependence(data_dependence_relation*, loop*)
.././../gcc-4.8.2/gcc/tree-data-ref.c:4169
0xbce98d compute_all_dependences(vec,
vec*, vec,
bool)
.././../gcc-4.8.2/gcc/tree-data-ref.c:4241
0xbcef83 compute_data_dependences_for_loop(loop*, bool, vec*, vec*,
vec*)
.././../gcc-4.8.2/gcc/tree-data-ref.c:4531
0xbcf18f analyze_all_data_dependences
.././../gcc-4.8.2/gcc/tree-data-ref.c:4639
0xbcf18f tree_check_data_deps()
.././../gcc-4.8.2/gcc/tree-data-ref.c:4687
0x8b62a7 check_data_deps
.././../gcc-4.8.2/gcc/tree-ssa-loop.c:330
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
sabrina@cioba:~/gcc$ clear
sabrina@cioba:~/gcc$ /home/sabrina/gcc/objdir/gcc/xgcc
-B/home/sabrina/gcc/objdir/gcc/
/home/sabrina/gcc/gcc-4.8.2/gcc/testsuite/gcc.dg/pr39794.c
-fno-diagnostics-show-caret -O2 -funroll-loops -fcheck-data-deps -o
./pr39794.c
(Number of distance vectors differ: Banerjee has 1, Omega has 0.
Banerjee dist vectors:
1
Omega dist vectors:
data dependence relation:
(Data Dep:
#(Data Ref:
# bb: 5
# stmt: _9 = *_8;
# ref: *_8;
# base_object: *a_5(D);
# Access function 0: {0B, +, 4}_1
#)
#(Data Ref:
# bb: 5
# stmt: *_14 = _21;
# ref: *_14;
# base_object: *a_5(D);
# Access function 0: {4B, +, 4}_1
#)
access_fn_A: {0B, +, 4}_1
access_fn_B: {4B, +, 4}_1
(subscript
iterations_that_access_an_element_twice_in_A: [1 + 1 * x_1]
last_conflict: 2147483646
iterations_that_access_an_element_twice_in_B: [0 + 1 * x_1]
last_conflict: 2147483646
(Subscript distance: 1 ))
inner loop index: 0
loop nest: (1 )
)
)
/home/sabrina/gcc/gcc-4.8.2/gcc/testsuite/gcc.dg/pr39794.c: In function ‘foo’:
/home/sabrina/gcc/gcc-4.8.2/gcc/testsuite/gcc.dg/pr39794.c:8:1: internal
compiler error: in compute_affine_dependence, at tree-data-ref.c:4170
0xbcc0d2 compute_affine_dependence(data_dependence_relation*, loop*)
.././../gcc-4.8.2/gcc/tree-data-ref.c:4169
0xbce98d compute_all_dependences(vec,
vec*, vec,
bool)
.././../gcc-4.8.2/gcc/tree-data-ref.c:4241
0xbcef83 compute_data_dependences_for_loop(loop*, bool, vec*, vec*,
vec*)
.././../gcc-4.8.2/gcc/tree-data-ref.c:4531
0xbcf18f analyze_all_data_dependences
.././../gcc-4.8.2/gcc/tree-data-ref.c:4639
0xbcf18f tree_check_data_deps()
.././../gcc-4.8.2/gcc/tree-data-ref.c:4687
0x8b62a7 check_data_deps
.././../gcc-4.8.2/gcc/tree-ssa-loop.c:330
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
Someone could also confirm this o
[Bug middle-end/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61950 Pat Haugen changed: What|Removed |Added Target|sparc-sun-solaris2.1[01]|sparc-sun-solaris2.1[01], ||powerpc64-unknown-linux-gnu CC||pthaugen at gcc dot gnu.org Host|sparc-sun-solaris2.1[01]|sparc-sun-solaris2.1[01], ||powerpc64-unknown-linux-gnu Build|sparc-sun-solaris2.1[01]|sparc-sun-solaris2.1[01], ||powerpc64-unknown-linux-gnu --- Comment #4 from Pat Haugen --- Seeing the same on powerpc64-unknown-linux-gnu (big-endian).
[Bug lto/53808] Undefined symbol when building a library with lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53808 --- Comment #13 from Jason Merrill --- Author: jason Date: Wed Jul 30 17:27:14 2014 New Revision: 213307 URL: https://gcc.gnu.org/viewcvs?rev=213307&root=gcc&view=rev Log: PR lto/53808 PR c++/61659 * pt.c (push_template_decl_real): Set DECL_COMDAT on templates. (check_explicit_specialization): Clear it on specializations. * decl.c (duplicate_decls, start_decl): Likewise. (grokmethod, grokfndecl): Set DECL_COMDAT on inlines. * method.c (implicitly_declare_fn): Set DECL_COMDAT. Determine linkage after setting the appropriate flags. * tree.c (decl_linkage): Don't check DECL_COMDAT. * decl2.c (mark_needed): Mark clones. (import_export_decl): Not here. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/decl2.c trunk/gcc/cp/method.c trunk/gcc/cp/pt.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/g++.dg/opt/devirt4.C
[Bug ipa/61659] [4.9/4.10 Regression] Extra undefined symbol because of devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61659 --- Comment #19 from Jason Merrill --- Author: jason Date: Wed Jul 30 17:27:20 2014 New Revision: 213308 URL: https://gcc.gnu.org/viewcvs?rev=213308&root=gcc&view=rev Log: PR c++/61659 PR c++/61687 Revert: gcc/c-family/ * c.opt (-fuse-all-virtuals): New. gcc/cp/ * decl2.c (mark_all_virtuals): New variable. (maybe_emit_vtables): Check it instead of flag_devirtualize. (cp_write_global_declarations): Set it and give helpful diagnostic if it introduces errors. * class.c (finish_struct_1): Check it. Removed: trunk/gcc/testsuite/g++.dg/template/dtor9a.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/decl2.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/g++.dg/template/dtor9.C
[Bug ipa/61659] [4.9/4.10 Regression] Extra undefined symbol because of devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61659 --- Comment #19 from Jason Merrill --- Author: jason Date: Wed Jul 30 17:27:20 2014 New Revision: 213308 URL: https://gcc.gnu.org/viewcvs?rev=213308&root=gcc&view=rev Log: PR c++/61659 PR c++/61687 Revert: gcc/c-family/ * c.opt (-fuse-all-virtuals): New. gcc/cp/ * decl2.c (mark_all_virtuals): New variable. (maybe_emit_vtables): Check it instead of flag_devirtualize. (cp_write_global_declarations): Set it and give helpful diagnostic if it introduces errors. * class.c (finish_struct_1): Check it. Removed: trunk/gcc/testsuite/g++.dg/template/dtor9a.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/decl2.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/g++.dg/template/dtor9.C
[Bug ipa/61659] [4.9/4.10 Regression] Extra undefined symbol because of devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61659 --- Comment #18 from Jason Merrill --- Author: jason Date: Wed Jul 30 17:27:14 2014 New Revision: 213307 URL: https://gcc.gnu.org/viewcvs?rev=213307&root=gcc&view=rev Log: PR lto/53808 PR c++/61659 * pt.c (push_template_decl_real): Set DECL_COMDAT on templates. (check_explicit_specialization): Clear it on specializations. * decl.c (duplicate_decls, start_decl): Likewise. (grokmethod, grokfndecl): Set DECL_COMDAT on inlines. * method.c (implicitly_declare_fn): Set DECL_COMDAT. Determine linkage after setting the appropriate flags. * tree.c (decl_linkage): Don't check DECL_COMDAT. * decl2.c (mark_needed): Mark clones. (import_export_decl): Not here. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/decl2.c trunk/gcc/cp/method.c trunk/gcc/cp/pt.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/g++.dg/opt/devirt4.C
[Bug c++/61687] [4.10 regression] -O PASS, -O2 report error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61687 --- Comment #5 from Jason Merrill --- Author: jason Date: Wed Jul 30 17:27:20 2014 New Revision: 213308 URL: https://gcc.gnu.org/viewcvs?rev=213308&root=gcc&view=rev Log: PR c++/61659 PR c++/61687 Revert: gcc/c-family/ * c.opt (-fuse-all-virtuals): New. gcc/cp/ * decl2.c (mark_all_virtuals): New variable. (maybe_emit_vtables): Check it instead of flag_devirtualize. (cp_write_global_declarations): Set it and give helpful diagnostic if it introduces errors. * class.c (finish_struct_1): Check it. Removed: trunk/gcc/testsuite/g++.dg/template/dtor9a.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/decl2.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/g++.dg/template/dtor9.C
[Bug lto/61967] New: regression: cannot link with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61967 Bug ID: 61967 Summary: regression: cannot link with -flto Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org I download tar-1.28 from ftp.gnu.org , and ./configure with CFLAGS='-pipe -O3 -flto -Wl,-S -Wl,--hash-style=gnu -Wl,-O1 -Wl,-z,relro' If I compile and link with gcc483, everything is fine, but with gcc491 I get: Making all in rmt make[2]: Entering directory '/mnt/new/src/tar-1.28/rmt' gcc -std=gnu99 -pipe -O3 -flto -Wl,-S -Wl,--hash-style=gnu -Wl,-O1 -Wl,-z,relro -L/usr/lib64 -L/lib64 -o rmt rmt.o ../gnu/libgnu.a /tmp/ccOs1raW.ltrans0.ltrans.o: In function `close_device': ccOs1raW.ltrans0.o:(.text+0x3b4): undefined reference to `umaxtostr' /tmp/ccOs1raW.ltrans0.ltrans.o: In function `main': ccOs1raW.ltrans0.o:(.text.startup+0x1a): undefined reference to `set_program_name' ccOs1raW.ltrans0.o:(.text.startup+0x29): undefined reference to `argp_version_setup' ccOs1raW.ltrans0.o:(.text.startup+0x1c4): undefined reference to `umaxtostr' ccOs1raW.ltrans0.o:(.text.startup+0x1e7): undefined reference to `full_write' ccOs1raW.ltrans0.o:(.text.startup+0x245): undefined reference to `safe_read' ccOs1raW.ltrans0.o:(.text.startup+0x25f): undefined reference to `umaxtostr' ccOs1raW.ltrans0.o:(.text.startup+0x282): undefined reference to `full_write' ccOs1raW.ltrans0.o:(.text.startup+0x295): undefined reference to `xstrdup' ccOs1raW.ltrans0.o:(.text.startup+0x3f8): undefined reference to `umaxtostr' ccOs1raW.ltrans0.o:(.text.startup+0x7cc): undefined reference to `umaxtostr' ccOs1raW.ltrans0.o:(.text.startup+0x860): undefined reference to `full_write' ccOs1raW.ltrans0.o:(.text.startup+0x89a): undefined reference to `xrealloc' ccOs1raW.ltrans0.o:(.text.startup+0x8c6): undefined reference to `xrealloc' collect2: error: ld returned 1 exit status Makefile:1266: recipe for target 'rmt' failed make[2]: *** [rmt] Error 1 make[2]: Leaving directory '/mnt/new/src/tar-1.28/rmt' Makefile:1348: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/mnt/new/src/tar-1.28' Makefile:1287: recipe for target 'all' failed make: *** [all] Error 2 Removing -flto leads to successful compilation.
[Bug lto/61967] regression: cannot link with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61967 --- Comment #2 from Andrew Pinski --- >../gnu/libgnu.a I bet it is due to how ../gnu/libgnu.a is generated. Does it use gcc-ar or just ar? For 4.9 and above, we use slim lto object files so it does not produce a symbol table that ar does not understand without a plugin and gcc-ar forces the plugin to be loaded.
[Bug fortran/61968] New: ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968 Bug ID: 61968 Summary: ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE Product: gcc Version: 4.10.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: jnorris at gcc dot gnu.org, pault at gcc dot gnu.org Created attachment 33216 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33216&action=edit Testcase (test.f90) Passing a TYPE(*) to CLASS(*) is properly rejected by the compiler, thus, there is no need to attempt to generate a virtual table for TYPE(*) – ignoring the problem that TYPE(*) has no real type. My suspicion is that this happens during resolving the generic call, triggered by the CLASS - even though the actual class call isn't and shouldn't be done. The generated function looks in assembly as follows - unsurprisingly, the assembler stumbles over it: .type __copy_TYPE(*)_0_.2366, @function Credit for finding the issue goes to Jim.
[Bug lto/61967] regression: cannot link with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61967 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Markus Trippelsdorf --- https://gcc.gnu.org/wiki/LinkTimeOptimizationFAQ#ar.2C_nm_and_ranlib
[Bug fortran/61933] Inquire on internal units
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933 Joost VandeVondele changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch, jvdelisle at gcc dot gnu.org Depends on||33055 --- Comment #1 from Joost VandeVondele --- actually, looking into preparing a patch for this I figured this is related to the old PR33055, and I would argue that the fix for that PR is incorrect... give n the quote from the standard. Also, it leads to surprising behavior: LOGICAL :: file_exists INTEGER :: istat CHARACTER(LEN=5) :: t istat=-42 INQUIRE(UNIT=-1,EXIST=file_exists,IOSTAT=istat) WRITE(6,*) file_exists,istat END now istat will be non-zero, but the inquire without istat will not generate a runtime error, nor jump to the ERR label if that would be present instead. The behavior can be understood seeing the use of create_dummy_iostat in trans-io.c, IMO a hack to catch this case.
[Bug c++/57397] Off-by-one error in diagnostic when calling variadic function template with too few arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57397 --- Comment #6 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Jul 30 20:06:29 2014 New Revision: 213310 URL: https://gcc.gnu.org/viewcvs?rev=213310&root=gcc&view=rev Log: /cp 2014-07-30 Paolo Carlini PR c++/57397 * pt.c (unify_arity): Add boolean parameter. (unify_too_few_arguments): Likewise. (type_unification_real): Diagnose correctly insufficient arguments in the presence of trailing variadic parameters; deducing multiple trailing packs as empty is fine. /testsuite 2014-07-30 Paolo Carlini PR c++/57397 * g++.dg/cpp0x/vt-57397-1.C: New. * g++.dg/cpp0x/vt-57397-2.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/vt-57397-1.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-57397-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/57397] Off-by-one error in diagnostic when calling variadic function template with too few arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57397 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #7 from Paolo Carlini --- Fixed.
[Bug tree-optimization/61964] [4.8 regression] krb5 database propagation enters infinite loop; reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964 --- Comment #3 from Anders Kaseorg --- (In reply to Richard Biener from comment #1) > The testcase is violating strict-aliasing rules as you access a struct head > as struct node here: Agree with ghudson here: n->prev points to &heads[2], not &heads[0]. Although assigning a casted struct head * to a struct node * is arguably sloppy, the standard does not prohibit it, as long as it is never dereferenced in that form.
[Bug lto/61969] New: wrong code by LTO on x86_64-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969 Bug ID: 61969 Summary: wrong code by LTO on x86_64-linux-gnu (affecting trunk, 4.9.x, and 4.8.x) Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: su at cs dot ucdavis.edu Created attachment 33217 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33217&action=edit test files and compilation script The current gcc trunk (as well as gcc 4.8.x and 4.9.x) miscompiles the attached code when using LTO on x86_64-linux-gnu in 64-bit mode (but not in 32-bit mode). This is a regression from 4.7.x. Sorry that the test case is still pretty complex. It seems very difficult to be reduced further --- any small changes to the code seem to hide the bug. $ gcc-trunk -v Using built-in specs. COLLECT_GCC=gcc-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk --enable-languages=c,c++ --disable-werror --enable-multilib Thread model: posix gcc version 4.10.0 20140730 (experimental) [trunk revision 213231] (GCC) $ $ compile.sh Usage: ./compile.sh $ compile.sh gcc-trunk 64 0; t -25246 $ compile.sh gcc-trunk 64 1; t -25246 $ compile.sh gcc-trunk 32 0; t -25246 $ compile.sh gcc-trunk 32 1; t 0 $ compile.sh gcc-4.9 32 1; t 0 $ compile.sh gcc-4.8 32 1; t 2052 $ compile.sh gcc-4.7 32 1; t -25246 $
[Bug ipa/61659] [4.9/4.10 Regression] Extra undefined symbol because of devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61659 --- Comment #20 from Jason Merrill --- Author: jason Date: Wed Jul 30 21:29:25 2014 New Revision: 213311 URL: https://gcc.gnu.org/viewcvs?rev=213311&root=gcc&view=rev Log: PR lto/53808 PR c++/61659 * pt.c (push_template_decl_real): Don't set DECL_COMDAT on friends. Added: trunk/gcc/testsuite/g++.dg/template/friend56.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug lto/53808] Undefined symbol when building a library with lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53808 --- Comment #14 from Jason Merrill --- Author: jason Date: Wed Jul 30 21:29:25 2014 New Revision: 213311 URL: https://gcc.gnu.org/viewcvs?rev=213311&root=gcc&view=rev Log: PR lto/53808 PR c++/61659 * pt.c (push_template_decl_real): Don't set DECL_COMDAT on friends. Added: trunk/gcc/testsuite/g++.dg/template/friend56.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug tree-optimization/61938] Vectorization not happening .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61938
--- Comment #6 from harmeeksingh at gmail dot com ---
Equivalent code when written by hand where tmp is a intermediate array . The
compiler
vectorizes both loops.
int k, i;
/* vectorize the compares */
for (i=0; i < arraysize; ++i) {
tmp[i] = (array[i] == compval);
}
/* another loop now set the result array */
for (k=0, i=0; i < arraysize; ++i) {
if (tmp[i])
{
result[k] = i;
k++;
}
}
[Bug lto/61967] regression: cannot link with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61967 --- Comment #3 from Дилян Палаузов --- Please include a link from https://gcc.gnu.org/wiki/LinkTimeOptimization to https://gcc.gnu.org/wiki/LinkTimeOptimizationFAQ and update the latter to state (The next version of binutils [as of 2014-05-04] will support automatic loading of the liblto_plugin.) I ask you for the first change, as searching for "gcc link time optimizations" in a search engine I find only the first link and cannot come to the idea that a FAQ exists. The second change indicates how outdated the message is, and makes clear in "the next version" is in the meantime released without updating the Wiki.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 aggrostyle at gmail dot com changed: What|Removed |Added CC||aggrostyle at gmail dot com --- Comment #18 from aggrostyle at gmail dot com --- Guys, a question... how can i apply the patch? I've read that i have to add: patch do url "https://gcc.gnu.org/bugzilla/attachment.cgi?id=33180"; sha1 "def0cb036a255175db86f106e2bb9dd66d19b702" end But i don't know WHERE to add that in the formula when i use brew edit gcc... Any help? Thanks!
[Bug c/59850] Support sparse-style pointer address spaces (type attributes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #33 from Tom Tromey --- My current patch fails on some of the sparse validation tests. E.g., attr-in-parameter.c: attr_in_parameter.c:8:4: warning: assignment from pointer to different address space [-Waddress-space] This happens due to this line: static int (A *p); I have yet to debug this one. Also from noderef.c I found out that sparse accepts "noderef" on non-pointer types: struct x __A x; I hadn't realized this was possible. It seems somewhat weird to me, but I suppose I'll update my patch to follow. This also affects address_space, as shown by typeof-attribute.c: unsigned int __percpu x;
[Bug lto/61967] regression: cannot link with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61967 --- Comment #4 from Дилян Палаузов --- (In reply to Andrew Pinski from comment #2) > >../gnu/libgnu.a > > I bet it is due to how ../gnu/libgnu.a is generated. Does it use gcc-ar or > just ar? For 4.9 and above, we use slim lto object files so it does not > produce a symbol table that ar does not understand without a plugin and > gcc-ar forces the plugin to be loaded. gnulib is proceeded with ar, as you can see below. The fix from https://sourceware.org/bugzilla/show_bug.cgi?id=14698 foreseen for the next release of binutils has not helped me. $ rm gnu/libgnu.a $ make V=1 make[4]: Entering directory '/mnt/new/src/tar-1.28/gnu' rm -f libgnu.a ar cru libgnu.a copy-acl.o set-acl.o allocator.o areadlink.o areadlinkat.o argmatch.o argp-ba.o argp-eexst.o argp-fmtstream.o argp-fs-xinl.o argp-help.o argp-parse.o argp-pin.o argp-pv.o argp-pvh.o argp-xinl.o argp-version-etc.o backupfile.o bitrotate.o c-ctype.o c-strcasecmp.o c-strncasecmp.o careadlinkat.o cloexec.o close-stream.o closeout.o opendir-safer.o dirname.o basename.o dirname-lgpl.o basename-lgpl.o stripslash.o exclude.o exitfail.o chmodat.o chownat.o fd-hook.o fdutimensat.o filenamecat-lgpl.o fprintftime.o full-write.o gettime.o hash.o human.o imaxtostr.o inttostr.o offtostr.o uinttostr.o umaxtostr.o localcharset.o malloca.o mbchar.o mbscasecmp.o mbuiter.o modechange.o openat-die.o parse-datetime.o priv-set.o progname.o acl-errno-valid.o file-has-acl.o qcopy-acl.o qset-acl.o quotearg.o safe-read.o safe-write.o save-cwd.o savedir.o se-context.o se-selinux.o stat-time.o statat.o strftime.o strnlen1.o tempname.o timespec.o unistd.o dup-safer.o fd-safer.o pipe-safer.o uniwidth/width.o unlinkdir.o utimens.o version-etc.o version-etc-fsf.o wctype-h.o xmalloc.o xalloc-die.o xgetcwd.o xsize.o xstrndup.o xstrtol.o xstrtoul.o xstrtol-error.o xstrtoumax.o xvasprintf.o xasprintf.o asnprintf.o chdir-long.o fcntl.o futimens.o getopt.o getopt1.o linkat.o openat-proc.o printf-args.o printf-parse.o regex.o selinux-at.o utimensat.o vasnprintf.o ranlib libgnu.a make[4]: Leaving directory '/mnt/new/src/tar-1.28/gnu'
[Bug lto/61967] regression: cannot link with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61967 --- Comment #5 from Дилян Палаузов --- Using gcc-ar instead of ar does not help: $grep AR\ = Makefile AR = gcc-ar ... $rm gnu/libgnu.a $make V=1 make[4]: Entering directory '/mnt/new/src/tar-1.28/gnu' rm -f libgnu.a gcc-ar cru libgnu.a copy-acl.o set-acl.o allocator.o areadlink.o areadlinkat.o argmatch.o argp-ba.o argp-eexst.o argp-fmtstream.o argp-fs-xinl.o argp-help.o argp-parse.o argp-pin.o argp-pv.o argp-pvh.o argp-xinl.o argp-version-etc.o backupfile.o bitrotate.o c-ctype.o c-strcasecmp.o c-strncasecmp.o careadlinkat.o cloexec.o close-stream.o closeout.o opendir-safer.o dirname.o basename.o dirname-lgpl.o basename-lgpl.o stripslash.o exclude.o exitfail.o chmodat.o chownat.o fd-hook.o fdutimensat.o filenamecat-lgpl.o fprintftime.o full-write.o gettime.o hash.o human.o imaxtostr.o inttostr.o offtostr.o uinttostr.o umaxtostr.o localcharset.o malloca.o mbchar.o mbscasecmp.o mbuiter.o modechange.o openat-die.o parse-datetime.o priv-set.o progname.o acl-errno-valid.o file-has-acl.o qcopy-acl.o qset-acl.o quotearg.o safe-read.o safe-write.o save-cwd.o savedir.o se-context.o se-selinux.o stat-time.o statat.o strftime.o strnlen1.o tempname.o timespec.o unistd.o dup-safer.o fd-safer.o pipe-safer.o uniwidth/width.o unlinkdir.o utimens.o version-etc.o version-etc-fsf.o wctype-h.o xmalloc.o xalloc-die.o xgetcwd.o xsize.o xstrndup.o xstrtol.o xstrtoul.o xstrtol-error.o xstrtoumax.o xvasprintf.o xasprintf.o asnprintf.o chdir-long.o fcntl.o futimens.o getopt.o getopt1.o linkat.o openat-proc.o printf-args.o printf-parse.o regex.o selinux-at.o utimensat.o vasnprintf.o ranlib libgnu.a make[4]: Leaving directory '/mnt/new/src/tar-1.28/gnu' ... make[2]: Entering directory '/mnt/new/src/tar-1.28/rmt' gcc -std=gnu99 -pipe -flto -O3 -Wl,-S -Wl,--hash-style=gnu -Wl,-O1 -Wl,-z,relro -L/usr/lib64 -L/lib64 -o rmt rmt.o ../gnu/libgnu.a /tmp/ccpoLHOH.ltrans0.ltrans.o: In function `close_device': ccpoLHOH.ltrans0.o:(.text+0x3b4): undefined reference to `umaxtostr' /tmp/ccpoLHOH.ltrans0.ltrans.o: In function `main': ccpoLHOH.ltrans0.o:(.text.startup+0x1a): undefined reference to `set_program_name' ccpoLHOH.ltrans0.o:(.text.startup+0x29): undefined reference to `argp_version_setup' ccpoLHOH.ltrans0.o:(.text.startup+0x1c4): undefined reference to `umaxtostr' ccpoLHOH.ltrans0.o:(.text.startup+0x1e7): undefined reference to `full_write' ccpoLHOH.ltrans0.o:(.text.startup+0x245): undefined reference to `safe_read' ccpoLHOH.ltrans0.o:(.text.startup+0x25f): undefined reference to `umaxtostr' ccpoLHOH.ltrans0.o:(.text.startup+0x282): undefined reference to `full_write' ccpoLHOH.ltrans0.o:(.text.startup+0x295): undefined reference to `xstrdup' ccpoLHOH.ltrans0.o:(.text.startup+0x3f8): undefined reference to `umaxtostr' ccpoLHOH.ltrans0.o:(.text.startup+0x7cc): undefined reference to `umaxtostr' ccpoLHOH.ltrans0.o:(.text.startup+0x860): undefined reference to `full_write' ccpoLHOH.ltrans0.o:(.text.startup+0x89a): undefined reference to `xrealloc' ccpoLHOH.ltrans0.o:(.text.startup+0x8c6): undefined reference to `xrealloc' collect2: error: ld returned 1 exit status Makefile:1266: recipe for target 'rmt' failed make[2]: *** [rmt] Error 1 make[2]: Leaving directory '/mnt/new/src/tar-1.28/rmt' Makefile:1348: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/mnt/new/src/tar-1.28' Makefile:1287: recipe for target 'all' failed make: *** [all] Error 2
[Bug lto/61967] regression: cannot link with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61967 --- Comment #6 from Andrew Pinski --- (In reply to Дилян Палаузов from comment #5) > Using gcc-ar instead of ar does not help: > > $grep AR\ = Makefile > AR = gcc-ar > ... > ranlib libgnu.a You need to use gcc-ranlib too otherwise the symbol table is also messed up.
[Bug c++/61970] New: array subscript is above array bounds [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61970 Bug ID: 61970 Summary: array subscript is above array bounds [-Werror=array-bounds] Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kaijun at seed dot net.tw In Gcc 4.6 before can compiler OK. but use GCC 4.8.2 (CentOS 7.0)can't comiler. if comment code //virtual ~PriceLst(); I don't know why and how to fixed it.
[Bug c++/61971] New: array subscript is above array bounds [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61971 Bug ID: 61971 Summary: array subscript is above array bounds [-Werror=array-bounds] Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kaijun at seed dot net.tw In Gcc 4.6 before can compiler OK. but use GCC 4.8.2 (CentOS 7.0)can't comiler. if comment code //virtual ~PriceLst(); I don't know why and how to fixed it.
[Bug c++/61971] array subscript is above array bounds [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61971
--- Comment #1 from kaijun ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --disable-libgcj
--with-isl=/builddir/build/BUILD/gcc-4.8.2-20140120/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.2-20140120/obj-x86_64-redhat-linux/cloog-install
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.2 20140120 (Red Hat 4.8.2-16) (GCC)
$ make -f Makefile2
make -f mytest2.mak all
g++ -c -pipe -D_LITTLE_ENDIAN_BYTE_ORDER_ -DLINUX -D_NOT_SOLARIS8
-DSYSTEM_TYPE=10 -ansi -Wno-deprecated -m64 -DUSE_MSG -DDEBUG_SQLITE -DLINUX
-DRMM_UNIX -DRUM_UNIX -DRMM_UNIX -DOS_LINUX -D_THREAD_SAFE -D_REENTRANT -Werror
-W -Wall -Wpointer-arith -Wcast-align -Wshadow -Wno-long-long
-Wstrict-aliasing=0 -Wformat=2 -Wno-deprecated -g -O2 -I/opt/IBM/llm/include -o
obj/mytest2.o mytest2.cpp
mytest2.cpp: In member function 'void std::vector<_Tp,
_Alloc>::_M_insert_aux(std::vector<_Tp, _Alloc>::iterator, const _Tp&) [with
_Tp = ProdBook; _Alloc = std::allocator; std::vector<_Tp,
_Alloc>::iterator = __gnu_cxx::__normal_iterator >; typename std::_Vector_base<_Tp, _Alloc>::pointer =
ProdBook*]':
mytest2.cpp:32:7: error: array subscript is above array bounds
[-Werror=array-bounds]
class ProdBook {
^
mytest2.cpp:32:7: error: array subscript is above array bounds
[-Werror=array-bounds]
cc1plus: all warnings being treated as errors
make[1]: *** [obj/mytest2.o] Error 1
make: *** [all] Error 2
=
//mytest2.cpp
#include
#include
#include
#include
#include
class CPriceLst;
class DPriceLst;
class DDPriceLst;
class ProdBook;
class PriceLst {
public:
virtual ~PriceLst();
};
class DPriceLst : public PriceLst
{
public:
};
class DDPriceLst : public DPriceLst
{
public:
};
class ProdBook {
public:
PriceLstm_bs_pr[2];
DPriceLst m_bs_d_pr[2]; // derived order lst
DDPriceLst m_bs_dd_pr[2]; // 2nd derived lst
ProdBook();
};
class OrderBook {
public:
std::vector m_prod;
};
int main() {
void *ptr=NULL;
ProdBook prod;
((OrderBook*)ptr)->m_prod.push_back(prod);
return 0;
}
~
[Bug c++/61971] array subscript is above array bounds [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61971 --- Comment #2 from Andrew Pinski --- *** Bug 61970 has been marked as a duplicate of this bug. ***
[Bug c++/61970] array subscript is above array bounds [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61970 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- . *** This bug has been marked as a duplicate of bug 61971 ***
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #19 from Alexander Bock --- (In reply to aggrostyle from comment #18) > Guys, a question... how can i apply the patch? I've read that i have to add: > > patch do > url "https://gcc.gnu.org/bugzilla/attachment.cgi?id=33180"; > sha1 "def0cb036a255175db86f106e2bb9dd66d19b702" > end > > But i don't know WHERE to add that in the formula when i use brew edit gcc... > > Any help? Thanks! Running this command while in the gcc source directory patch -p1 < patchfile where patchfile is the name you saved Clarke's attachment with is a quick way to apply it; I'm not sure about homebrew specifics as I was building from source manually.
[Bug c++/61970] array subscript is above array bounds [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61970 --- Comment #2 from kaijun --- For Andrew Pinski, I am sorry, past again bug: 61970 and 61971 is the same. Thanks.
[Bug c/61972] New: relocation truncated to fit: R_PPC_VLE_REL24 against symbol "xxx" for VLE instruction on binutils-2.24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61972 Bug ID: 61972 Summary: relocation truncated to fit: R_PPC_VLE_REL24 against symbol "xxx" for VLE instruction on binutils-2.24 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: wangy850626 at gmail dot com For binuitls-2.24, on long jump for BOOKE instructions, assembler can relocate successfully, on long jump for VLE instrucions, assembler can not relocate successfully, so linker will report:"relocation truncated to fit: R_PPC_VLE_REL24 against symbol "xxx"
[Bug c/61972] relocation truncated to fit: R_PPC_VLE_REL24 against symbol "xxx" for VLE instruction on binutils-2.24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61972 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #1 from Andrew Pinski --- Please file this with the binutils project at https://sourceware.org/bugzilla/
[Bug tree-optimization/61964] [4.8 regression] krb5 database propagation enters infinite loop; reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964 --- Comment #4 from Anders Kaseorg --- Another bisect between 4.7 and 4.8 shows that the bug appeared with r189321 (bug 52009). My test case has triggers the bug in more versions than Kerberos does: as far as I can tell, Kerberos was unaffected until r192604.
