[Bug rtl-optimization/60901] [4.8/4.9 Regression] ICE: SIGSEGV in add_to_deps_list with -fsel-sched-pipelining-outer-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60901 --- Comment #8 from Andrey Belevantsev --- Sorry, Uros asked me to wait a bit while the patch is on trunk and at the time the 4.8 branch got freezed, so I've postponed backporting. I will take care of it.
[Bug rtl-optimization/61278] ICE with LTO (lto-wrapper failed) on x86_64-linux-gnu in 64-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61278 --- Comment #4 from zqchen at gcc dot gnu.org --- Author: zqchen Date: Mon May 26 06:40:57 2014 New Revision: 210922 URL: http://gcc.gnu.org/viewcvs?rev=210922&root=gcc&view=rev Log: ChangeLog: 2014-05-26 Zhenqiang Chen PR rtl-optimization/61278 * shrink-wrap.c (move_insn_for_shrink_wrap): Check df_live. testsuite/ChangeLog: 2014-05-26 Zhenqiang Chen * gcc.dg/lto/pr61278_0.c: New test. * gcc.dg/lto/pr61278_1.c: New test. Added: trunk/gcc/testsuite/gcc.dg/lto/pr61278_0.c trunk/gcc/testsuite/gcc.dg/lto/pr61278_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/shrink-wrap.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/61225] [4.10 Regression] Several new failures after r210458 on x86_64-*-* with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61225 --- Comment #8 from zqchen at gcc dot gnu.org --- Author: zqchen Date: Mon May 26 06:11:33 2014 New Revision: 210921 URL: http://gcc.gnu.org/viewcvs?rev=210921&root=gcc&view=rev Log: ChangeLog: 2014-05-26 Zhenqiang Chen PR rtl-optimization/61220 Part of PR rtl-optimization/61225 * shrink-wrap.c (move_insn_for_shrink_wrap): Skip SP and FP adjustment insn; skip split_edge for a block with only one successor. testsuite/ChangeLog: 2014-05-26 Zhenqiang Chen * gcc.dg/pr61220.c: New test. * gcc.dg/shrink-wrap-loop.c: Disable for x86_64 -m32 mode. Added: trunk/gcc/testsuite/gcc.dg/pr61220.c Modified: trunk/gcc/ChangeLog trunk/gcc/shrink-wrap.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/shrink-wrap-loop.c
[Bug rtl-optimization/61220] [4.10 Regression] ICE on valid code at -O2 on x86_64-linux-gnu in maybe_record_trace_start, at dwarf2cfi.c:2239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61220 --- Comment #5 from zqchen at gcc dot gnu.org --- Author: zqchen Date: Mon May 26 06:11:33 2014 New Revision: 210921 URL: http://gcc.gnu.org/viewcvs?rev=210921&root=gcc&view=rev Log: ChangeLog: 2014-05-26 Zhenqiang Chen PR rtl-optimization/61220 Part of PR rtl-optimization/61225 * shrink-wrap.c (move_insn_for_shrink_wrap): Skip SP and FP adjustment insn; skip split_edge for a block with only one successor. testsuite/ChangeLog: 2014-05-26 Zhenqiang Chen * gcc.dg/pr61220.c: New test. * gcc.dg/shrink-wrap-loop.c: Disable for x86_64 -m32 mode. Added: trunk/gcc/testsuite/gcc.dg/pr61220.c Modified: trunk/gcc/ChangeLog trunk/gcc/shrink-wrap.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/shrink-wrap-loop.c
[Bug plugins/61176] [4.9/4.10 Regression] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176 --- Comment #9 from Andrew Macleod --- so. Include them all with an accumulator file as suggested? Over a run of multiple generations you have to expect some sort of flux in include structure, especially since we don't guarantee much. The only way I see you can have any kind of stability is to have a standard file you include which can adjust and include whatever is needed for any given release.
[Bug other/61300] powerpc64le miscompile with K&R-style function definition at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300 --- Comment #2 from Alan Modra --- Created attachment 32854 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32854&action=edit quick and dirty fix This fixes the problem in a fairly obvious way, but I think we can use a more refined approach that doesn't need a new INCOMING_REG_PARM_STACK_SPACE..
[Bug other/61313] New: configure incorrectly strips $target_alias from PLUGIN_LD_SUFFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61313 Bug ID: 61313 Summary: configure incorrectly strips $target_alias from PLUGIN_LD_SUFFIX Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: pageexec at gmail dot com When gcc is configured using --with-plugin-ld=/some/path/x86_64-pc-linux-gnu-hjl-master/bin/ld the resulting ld path will be reduced to the incorrect /some/path/hjl-master/bin/ld (for a x86_64-pc-linux-gnu target). This change was introduced by git commit 61f41b94c58c64e7334d97df57d6467cb1c7b70e and is part of gcc 4.8+.
[Bug c++/61312] variable function parameters declared as const in the class may not be declared as const in the function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61312 --- Comment #3 from Alexis Wilke --- Wow! I see that is now... "normal behavior". If you ask me, it sucks. But well... I suppose I don't count. Thank you for the PDF reference.
[Bug other/61300] powerpc64le miscompile with K&R-style function definition at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED CC||amodra at gmail dot com Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com --- Comment #1 from Alan Modra --- So, the "writes way past this" is writing into the parameter save area. compare_kr is assuming that it was called with a parameter save area because it isn't prototyped, but that is quite wrong because when compiling the function body we don't know how the function was called. A call may well have a prototype in scope, and thus not set up a parameter save area. It's a bug in rs6000_function_parms_need_stack. This function can't blindly test !prototype_p (fun).
[Bug target/61249] _mm_frcz_ss, _mm_frcz_sd: __builtin_ia32_vfrczss, __builtin_ia32_vfrczsd require 2 arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61249 --- Comment #8 from Michael Tautschnig --- I've just updated the patch to include a similar amendment for the __builtin_ia32_mpsadbw256 function. I'll do as suggested and will post to gcc-patches. Best, Michael
[Bug target/61249] _mm_frcz_ss, _mm_frcz_sd: __builtin_ia32_vfrczss, __builtin_ia32_vfrczsd require 2 arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61249 Michael Tautschnig changed: What|Removed |Added Attachment #32843|0 |1 is obsolete|| --- Comment #7 from Michael Tautschnig --- Created attachment 32853 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32853&action=edit Update documentation, incl mpsadbw256
[Bug c++/61312] variable function parameters declared as const in the class may not be declared as const in the function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61312 --- Comment #2 from Jonathan Wakely --- http://www.dansaks.com/articles/2000-02%20Top-Level%20cv-Qualifiers%20in%20Function%20Parameters.pdf
[Bug c++/61312] variable function parameters declared as const in the class may not be declared as const in the function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61312 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID Severity|major |normal --- Comment #1 from Jonathan Wakely --- Yes, that's how C++ works. Top-level const qualifiers are not part of a function signature. This is not a bug, definitely not one with "major" severity!
[Bug c++/61312] New: variable function parameters declared as const in the class may not be declared as const in the function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61312
Bug ID: 61312
Summary: variable function parameters declared as const in the
class may not be declared as const in the function
definition
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alexis at m2osw dot com
In the following code, the functions test() and foo() are both declared with a
flags parameter which is marked const. The declaration of the actual functions
(blah::foo() and blah::test() below the class declaration) do not specify the
const modifier and yet the compiler does not complain.
This happens with any number of parameters in the function declarations. It
does not happen with complex types (other classes) only basic types like int.
Since I may want to overload such functions, it is a problem. ("int" and "int
const" are not supposed to be the same type.)
class blah
{
public:
blah() {}
void test(int const flags);
private:
bool foo(int const flags);
int f_test;
};
bool blah::foo(int flags)
{
if(flags & 0x10)
{
f_test = 3;
}
else
{
f_test = 1;
}
return (flags & 0x03) != 0;
}
void blah::test(int flags)
{
flags |= 0x80;
foo(flags | 0x10);
}
int main()
{
blah a;
a.test(3);
return 0;
}
[Bug libfortran/61310] Regression, CTIME intrinsic incorrect result string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61310 Janne Blomqvist changed: What|Removed |Added URL||https://gcc.gnu.org/ml/gcc- ||patches/2014-05/msg02124.ht ||ml Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org --- Comment #1 from Janne Blomqvist --- Patch at https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02124.html
[Bug plugins/61311] New: missing LTO/WPA serialization API for use by regular IPA passes implemented in a plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61311 Bug ID: 61311 Summary: missing LTO/WPA serialization API for use by regular IPA passes implemented in a plugin Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins Assignee: unassigned at gcc dot gnu.org Reporter: pageexec at gmail dot com I recently faced the problem of implementing the four summary read/write callbacks for an IPA pass in a plugin. It turned out that the high level APIs for creating the input/output streams (e.g., create_output_block) expect 'enum lto_section_type' (instead of, say, a string). Given that this enum obviously cannot be expanded without patching the compiler itself, using the serialization API from a plugin requires some code duplication to avoid calling lto_get_section_name() deep down and the manual construction of the ELF section name. Given that the enum isn't used for much else but to look up the basic section name in lto_section_name[] and some statistics gathering, I think its use for constructing the streams (and in particular the section name) should be deprecated and instead plugins (and even in-tree users) should just be able to provide their part of the section name as a simple string instead. The second problem is the usual case of missing headers, I had to manually install the following ones for gcc 4.9: gcc/lto-streamer.h gcc/gcov-io.h gcc/data-streamer.h gcc/lto-compress.h gcc/lto/lto.h /gcc/gcov-iov.h
[Bug plugins/61176] [4.9/4.10 Regression] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176 PaX Team changed: What|Removed |Added CC||pageexec at gmail dot com --- Comment #8 from PaX Team --- I maintain a compatibility header for gcc plugins that also happens to include all the headers that we needed so far: https://www.grsecurity.net/~paxguy1/gcc-common.h (this copy may not always be up-to-date, the latest version is inside the PaX patch). As for include-what-you-use, I think it's not a viable model for plugins that want to support a range of gcc versions...
[Bug libfortran/61310] New: Regression, CTIME intrinsic incorrect result string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61310
Bug ID: 61310
Summary: Regression, CTIME intrinsic incorrect result string
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jb at gcc dot gnu.org
As a result of PR 47432, the CTIME intrinsic was changed to use the ctime_r()
function if available instead of the C stdlib ctime(). However, due to some
problems that was changed to use strftime with the "%c" specifier, see PR
47802.
Now it seems that on the mingw target, strftime(...,"%c",...) doesn't produce
the same output as ctime{_r}() *sigh*, see
https://stackoverflow.com/questions/23787340/format-of-ctime-output-in-fortran
.
Probably we could use something like the implementation suggested in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802#c14
[Bug libfortran/61187] valgrind errors if stdin is closed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61187 Janne Blomqvist changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Janne Blomqvist --- Fixed on 4.7/4.8/4.9/trunk, closing.
[Bug libfortran/61187] valgrind errors if stdin is closed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61187 --- Comment #5 from Janne Blomqvist --- Author: jb Date: Sun May 25 19:29:00 2014 New Revision: 210914 URL: http://gcc.gnu.org/viewcvs?rev=210914&root=gcc&view=rev Log: PR 61187 Avoid reading uninitialized memory. 2014-05-25 Janne Blomqvist Backport from trunk. PR libfortran/61187 * io/unix.c (raw_close): Check if s->fd is -1. (fd_to_stream): Check return value of fstat(), handle error. Modified: branches/gcc-4_8-branch/libgfortran/ChangeLog branches/gcc-4_8-branch/libgfortran/io/unix.c
[Bug target/60925] [4.9/4.10 Regression] hppa: can't find a register in class 'R1_REGS' while reloading 'asm'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925
--- Comment #7 from dave.anglin at bell dot net ---
On 25-May-14, at 7:11 AM, aaro.koskinen at iki dot fi wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925
>
> --- Comment #6 from Aaro Koskinen ---
> Created attachment 32852
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32852&action=edit
> Simplified reproducer.
>
> I tried to make a simpler reproducer.
Thanks for simplifying the test case. The problem is now clear.
>
> $ hppa-linux-gnu-gcc pr60925.c -c -O2 -Wall -g -fPIC
> pr60925.c: In function 'foo':
> pr60925.c:6:9: error: can't find a register in class 'R1_REGS' while
> reloading
> 'asm'
> asm volatile(
> ^
The problem is the argument "futex" used in the asm. When generating
PIC code, register
%r1 is needed for position independent loads and stores from memory.
In the test, both statements involving __lll_mutex_lock are needed to
trigger the
error. Essentially, reload fails to handle the reloads needed for
&lock because the
asm clobbers %r1 and %r1 is needed for the reload.
Possibly, reload should be able to do this because the reload insns
should be emitted
before %r1 is clobbered by the asm, but reload is complicated.
A better fix is to ensure that the futex argument is placed in a
general register
that is not clobbered by the asm. This has to happen anyway. For
example,
static inline int __attribute__((always_inline))
__lll_mutex_lock(int *futex, int private)
{
register int *f asm ("r5") = futex;
...
The other fix is to not inline __lll_mutex_lock. Then, one is sure
that futex will be
in %r26 on entry, and it can be copied to another general register
without %r1 being
needed.
Dave
--
John David Anglindave.ang...@bell.net
[Bug c++/22434] [3.4/4.0/4.1 regression] ICE in simplify_{,gen_}subreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22434
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #11 from Harald van Dijk ---
(In reply to Jason Merrill from comment #10)
I was about to report a new bug, but I think that you have already fixed the
problem here. Perhaps the test cases I was going to suggest would still be
useful to add:
struct T;
struct S { operator T(); };
struct T { operator S(); };
const S f();
volatile T g();
void h() { true ? f() : g(); }
or
struct S { S(void *); operator int(); };
const S f();
void g() { true ? f() : 1; }
are accepted by GCC 4.9 without any diagnostic. Take out one of the bad
conversions, and the other causes the correct error to be shown. (-pedantic
causees the bad conversions to be rejected earlier, but the errors here are
errors that are supposed to show up even without -pedantic, and normally they
do.)
[Bug middle-end/61141] [4.10 Regression] c-common.c:1502:1: ICE: in reset_insn_used_flags, at emit-rtl.c:2677
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61141 John David Anglin changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #7 from John David Anglin --- On hppa64-hp-hpux11.11, this bug was introduced by the following change: 2014-05-05 Richard Biener * passes.c (execute_function_todo): Don't reset TODO_verify_ssa from last_verified if update_ssa ran. Move TODO_verify_rtl_sharing under the TODO_verify_il umbrella.
[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363 vincenzo Innocente changed: What|Removed |Added Version|4.7.0 |4.9.1 --- Comment #21 from vincenzo Innocente --- is "Auto Cloning" foreseen to be included anytime soon? It looks to me that it is not "yet" supported in gcc 4.9.0
[Bug tree-optimization/61279] [4.10 Regression] ICE in loop_preheader_edge, at cfgloop.c:1668 w/ -O1 -ftree-loop-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61279
--- Comment #4 from Arseny Solokha ---
I even have another reproducer which is basically identical to the original one
but not completely.
int t;
int n[1] = { 0 };
void
x(void)
{
int v;
int r;
int i[4] = { 0 };
for (v = 0; v < 1; ++v) {
++i[3];
for (r = 0; r < 1; ++r) {
for (t = 0; t < 1; ++t)
return;
for (t = 0; t < 1; ++t)
/* Irregardless of i's declared size, the ICE only occurs
when the array subscript on lines 18 and 11 is exactly 3
(I've checked only the nearest values, however). */
i[3] = n[t];
for (t = 0; t < 1; ++t)
return;
}
}
}
[Bug c/56724] sub-optimal location in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Version|unknown |4.10.0 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #10 from Marek Polacek --- Taking now.
[Bug fortran/55789] [4.7 Regression] Needless realloc with array constructor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55789 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #19 from Dominique d'Humieres --- Test results at r210894 posted at https://gcc.gnu.org/ml/gcc-testresults/2014-05/msg02224.html. Closing as FIXED.
[Bug fortran/61138] [4.8/4.9/4.10 Regression] Wrong code with pointer-bounds remapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61138 --- Comment #4 from Mikael Morin --- (In reply to Mikael Morin from comment #2) > gfc_trans_pointer_assignment sets lse.descriptor_only before calling > gfc_conv_expr_descriptor (for the lhs), and later on reuses lse for other > things, without clearing descriptor_only. The proper fix would avoid reusing any gfc_se struct entirely; a more humble, ad hoc fix could look like this: diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c index 5a50122..9748ade 100644 --- a/gcc/fortran/trans-expr.c +++ b/gcc/fortran/trans-expr.c @@ -6684,2 +6684,3 @@ gfc_trans_pointer_assignment (gfc_expr * expr1, gfc_expr * expr2) lse.expr = tmp; + lse.descriptor_only = 0; lse.direct_byref = 1; @@ -6699,2 +6700,3 @@ gfc_trans_pointer_assignment (gfc_expr * expr1, gfc_expr * expr2) lse.direct_byref = 1; + lse.descriptor_only = 0; gfc_conv_expr_descriptor (&lse, expr2); @@ -6750,2 +6752,3 @@ gfc_trans_pointer_assignment (gfc_expr * expr1, gfc_expr * expr2) lse.direct_byref = 1; + lse.descriptor_only = 0; gfc_conv_expr_descriptor (&lse, expr2);
[Bug c++/61292] auto keyword to vector reference generates wrong alignment move (causing runtime segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61292
vincenzo Innocente changed:
What|Removed |Added
Summary|auto keyword to vector |auto keyword to vector
|reference generates wrong |reference generates wrong
|alignment move |alignment move (causing
||runtime segfault)
--- Comment #1 from vincenzo Innocente ---
interesting enough
void add14(float * x, float y, float32x4_t v) {
decltype(auto) k1 = *(float32x4a4_t*)(x);
decltype(auto) k2 = *(float32x4a4_t*)(x);
k1 +=v;
k2 += k1+v;
}
generates
__Z5add14PffU8__vectorf:
LFB5:
vaddps(%rdi), %xmm1, %xmm0
vaddps%xmm0, %xmm0, %xmm0
vaddps%xmm1, %xmm0, %xmm1
vmovups%xmm1, (%rdi)
ret
so c++11 auto is loosing the alignment...
is this "standard" or bug?
[Bug target/60925] [4.9/4.10 Regression] hppa: can't find a register in class 'R1_REGS' while reloading 'asm'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925 --- Comment #6 from Aaro Koskinen --- Created attachment 32852 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32852&action=edit Simplified reproducer. I tried to make a simpler reproducer. $ hppa-linux-gnu-gcc pr60925.c -c -O2 -Wall -g -fPIC pr60925.c: In function 'foo': pr60925.c:6:9: error: can't find a register in class 'R1_REGS' while reloading 'asm' asm volatile( ^ pr60925.c:6:9: error: can't find a register in class 'R1_REGS' while reloading 'asm' asm volatile( ^ pr60925.c:6:9: error: 'asm' operand has impossible constraints asm volatile( ^ pr60925.c:6:9: error: 'asm' operand has impossible constraints asm volatile( ^
[Bug middle-end/57625] internal compiler error: seg fault when building gcc 4.7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57625 --- Comment #6 from Mikael Pettersson --- The failure of 4.7 being built w/ --disable-bootstrap by 4.8+ stopped with the PR54638 fix in r191605. It's clear that the problem was undefined behaviour in 4.7.2, not a wrong-code error in 4.8+.
[Bug libgcc/61309] New: cilk-plus tests fail with: hidden symbol `__cpu_model' in /x/gcc/testsuite/g++/../../libgcc.a(cpuinfo.o) is referenced by DSO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61309 Bug ID: 61309 Summary: cilk-plus tests fail with: hidden symbol `__cpu_model' in /x/gcc/testsuite/g++/../../libgcc.a(cpuinfo.o) is referenced by DSO Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org CC: gnugcc at marino dot st Target: x86_64-unknown-dragonfly3.6 On the new DragonFlyBSD target loads of cilk-plus tests fail with this error: /usr/libexec/binutils222/elf/ld.bfd: ./reduction-1.exe: hidden symbol `__cpu_model' in /mnt/scratch/dfly/gcc/testsuite/g++/../../libgcc.a(cpuinfo.o) is referenced by DSO /usr/libexec/binutils222/elf/ld.bfd: final link failed: Bad value collect2: error: ld returned 1 exit status
[Bug go/61308] New: gccgo: ICE in Expression::check_bounds [GoSmith]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61308 Bug ID: 61308 Summary: gccgo: ICE in Expression::check_bounds [GoSmith] Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: dvyukov at google dot com CC: cmang at google dot com Created attachment 32851 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32851&action=edit reproducer gcc version 4.10.0 20140516 (experimental) (GCC) The program is attached. go build -compiler=gccgo main go1: internal compiler error: in check_bounds, at go/gofrontend/expressions.cc:480 0x5a3e71 Expression::check_bounds(Expression*, Location) ../../gcc/go/gofrontend/expressions.cc:480 0x5b89fd Array_index_expression::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/expressions.cc:10263 0x5aeb06 Type_conversion_expression::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/expressions.cc:3290 0x608076 Temporary_statement::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/statements.cc:452 0x5db097 Block::get_backend(Translate_context*) ../../gcc/go/gofrontend/gogo.cc:5454 0x60741c Block_statement::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/statements.cc:1811 0x5db097 Block::get_backend(Translate_context*) ../../gcc/go/gofrontend/gogo.cc:5454 0x5dc925 Function::build(Gogo*, Named_object*) ../../gcc/go/gofrontend/gogo.cc:5062 0x5ddc57 Named_object::get_backend(Gogo*, std::vector >&, std::vector >&, std::vector >&) ../../gcc/go/gofrontend/gogo.cc:6753 0x5e2b5c Gogo::write_globals() ../../gcc/go/gofrontend/gogo.cc:1136
[Bug go/61307] New: gccgo: ICE in Create_function_descriptors::expression [GoSmith]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61307 Bug ID: 61307 Summary: gccgo: ICE in Create_function_descriptors::expression [GoSmith] Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: dvyukov at google dot com CC: cmang at google dot com Created attachment 32850 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32850&action=edit reproducer gcc version 4.10.0 20140516 (experimental) (GCC) The program is attached. go build -compiler=gccgo main go1: internal compiler error: in descriptor, at go/gofrontend/gogo.cc:4572 0x5d0f40 Function::descriptor(Gogo*, Named_object*) ../../gcc/go/gofrontend/gogo.cc:4572 0x5d41ee Create_function_descriptors::expression(Expression**) ../../gcc/go/gofrontend/gogo.cc:2543 0x5a0e2d Expression::traverse(Expression**, Traverse*) ../../gcc/go/gofrontend/expressions.cc:43 0x5d1f5c Variable::traverse_expression(Traverse*, unsigned int) ../../gcc/go/gofrontend/gogo.cc:5594 0x5d1d70 Block::traverse(Traverse*) ../../gcc/go/gofrontend/gogo.cc:5345 0x5d1e9e Function::traverse(Traverse*) ../../gcc/go/gofrontend/gogo.cc:4549 0x5d4cb2 Bindings::traverse(Traverse*, bool) ../../gcc/go/gofrontend/gogo.cc:7144 0x5d4f91 Gogo::traverse(Traverse*) ../../gcc/go/gofrontend/gogo.cc:2187 0x5db6f1 Gogo::create_function_descriptors() ../../gcc/go/gofrontend/gogo.cc:2627 0x5cea18 go_parse_input_files(char const**, unsigned int, bool, bool) ../../gcc/go/gofrontend/go.cc:97
