[Bug c++/65255] std::thread does not work for cross compiling on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65255 --- Comment #5 from Andrew Pinski --- arm-* defaults to earlier arm than v7 which does not have atomics in the ISA. Your native compiler most likely defaulted to armv7 which uses the atomic instructions directly. Can you provide the output of gcc -v that you are running natively and most likely see the default cpu/arch that is being selected.
[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66358 --- Comment #16 from David Binderman --- Created attachment 36167 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36167&action=edit C source code
[Bug libfortran/67140] undefined reference to _gfortran_mvbits_i16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67140 --- Comment #13 from Francois-Xavier Coudert --- (In reply to kargl from comment #6) > The GFORTRAN_1.6 section of the symbol map where I've inserted > the _gfortan_mvbits_i16 symbol does not exist in 5-branch. If > the other functions in this section are backported, then this > function can also be backported. No a regression, not that critical, so not sure it warrants a backport.
[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66358
--- Comment #17 from David Binderman ---
I had a go at cross compiling Linux kernel for sh, and got something similar
with gcc 5.1.1 dated 20150618
$ sh-linux-gnu-gcc -c -O2 bug224.c
drivers/hwmon/w83627ehf.c: In function ‘show_caseopen’:
drivers/hwmon/w83627ehf.c:1774:1: error: insn does not satisfy its constraints:
(insn 135 111 136 2 (set:SI (reg:SI 1 r1)
(sign_extend:SI (mem:QI (plus:SI (reg/f:SI 8 r8 [175])
(const_int 12 [0xc])) [0 MEM[(struct
sensor_device_attribute_2 *)attr_6(D)].index+0 S1 A32])))
drivers/hwmon/w83627ehf.c:1772 231 {*extendqisi2_compact_mem_disp}
(nil))
drivers/hwmon/w83627ehf.c:1774:1: internal compiler error: in
extract_constrain_insn, at recog.c:2246
Problem seems to go away when I add flag -mlra, so I have a workaround.
Test case attached.
[Bug go/67180] New: Gccgo does not support MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67180 Bug ID: 67180 Summary: Gccgo does not support MIPS Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: 63877278 at qq dot com CC: 63877278 at qq dot com, cmang at google dot com Target Milestone: --- Host: mips64 Target: mips64 Gccgo does not support MIPS
[Bug tree-optimization/66828] [5/6 Regression] gcc/tree-ssa-math-opts.c:2182:38: runtime error: left shift of 72057594037927936 by 8 places cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66828 --- Comment #12 from Thomas Preud'homme --- Author: thopre01 Date: Tue Aug 11 07:58:07 2015 New Revision: 226775 URL: https://gcc.gnu.org/viewcvs?rev=226775&root=gcc&view=rev Log: 2015-08-11 Thomas Preud'homme Backport from mainline 2015-07-28 Thomas Preud'homme gcc/ PR tree-optimization/66828 * tree-ssa-math-opts.c (perform_symbolic_merge): Change type of inc from int64_t to uint64_t. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/tree-ssa-math-opts.c
[Bug go/67180] Gccgo does not support MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67180 --- Comment #1 from tsuibin <63877278 at qq dot com> --- I added MIPS support to gccgo. But I don't know how to submit a patch to gccgo My code is here : https://github.com/tsuibin/libgo_mips_elf_support/blob/master/libgo_mips_elf_support.patch and here: https://github.com/tsuibin/libffi_mips_go_closure/blob/master/libffi_mips_go_closure.patch
[Bug tree-optimization/66828] [5/6 Regression] gcc/tree-ssa-math-opts.c:2182:38: runtime error: left shift of 72057594037927936 by 8 places cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66828 Markus Trippelsdorf changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Markus Trippelsdorf --- Fixed, thanks.
[Bug target/67172] [5/6 regression] i686-w64-mingw32 dwarf2 bootstrap fails with undefined reference to __EH_FRAME_BEGIN__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67172 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.3
[Bug fortran/67171] [6 regression] sourced allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67171 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0 Summary|[6.0 regression] sourced|[6 regression] sourced |allocation |allocation
[Bug regression/67181] New: wrong dependence may cause runtime bug on some target with vliw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67181
Bug ID: 67181
Summary: wrong dependence may cause runtime bug on some target
with vliw
Product: gcc
Version: 4.9.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
as we known , some target with vliw, then some insns can be issued at the same
cycle.
in file sched-deps.c, the following code are add for improve the speed of
compile. But it may bring wrong dependence.
/* Pending lists can't get larger with a readonly context. */
if (!deps->readonly
&& ((deps->pending_read_list_length +
deps->pending_write_list_length)
> MAX_PENDING_LIST_LENGTH))
{
/* Flush all pending reads and writes to prevent the pending lists
from getting any larger. Insn scheduling runs too slowly when
these lists get long. When compiling GCC with itself,
this flush occurs 8 times for sparc, and 10 times for m88k using
the default value of 32. */
flush_pending_lists (deps, insn, false, true);
}
else
+ when entry the above trunk, true-deps are mistaken for anti-deps.
+ for example:
+
+ store a3, mem1 (suppose we flush pending_write_insns here)
+ load a4, mem1
+
+ here, store is pushed into last_pending_memory_flush when
pending_read_insns
+ and pending_write_insns are flushed. The sequential load is reckoned as
+ anti-dependent rather than true-dependent on the previous store.
+
+ In general, the vliw {store a3,mem1; load a3, mem1} may be recognized as
read first , then write, i.e., it executed similar to anti-dependent. In this
case, the true-dependent reckoned as anti-dependent will bring runtime error.
[Bug c/67167] cilkplus vectorization problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67167 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-11 CC||kyukhin at gcc dot gnu.org Depends on||66502 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- t.c:28:13: note: === get_loop_niters === t.c:28:13: note: not vectorized: number of iterations cannot be computed. t.c:28:13: note: bad loop form. t.c:22:6: note: vectorized 0 loops in function. Which is probably because the loop has two IVs and a combined exit test: : # _32 = PHI <0(4), _21(6)> # _33 = PHI <0(4), _22(6)> ... _21 = _32 + 1; _22 = _33 + 1; _25 = size_9(D) > _22; _23 = size_9(D) > _21; _24 = _23 & _25; if (_24 != 0) goto ; else goto ; related to PR66502 (proposed patch helps and makes the testcase vectorized, but as noted in the PR regresses another case). Not sure if this can be reasonably addressed in Cilk+ lowering as well? (generate a single IV) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66502 [Bug 66502] SCCVN can't handle PHIs optimistically optimally
[Bug fortran/67170] PRE can't hoist out a readonly argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67170
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-08-11
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
Ah.
# USE = nonlocal escaped { D.3438 }
# CLB = nonlocal escaped
foo (&D.3438);
As it clobbers nonlocal it clobbers the incoming argument :/ Because of course
as the argument is pointing to possibly global memory it can access it via
other means than through the argument - and the function attribute in use
(".r") just means accesses through the first argument do not modify the
contents pointed to.
I think Fortran guarantees that things passed as argument are not modified
in other ways (or it makes that undefined). Not sure about called functions
though.
Now. In principle I think C says that with
void foo (int * __restrict p)
{
...
bar ();
...
}
bar () can only access *p through the use of p or a derived pointer. So
int x;
bar()
{
x = 1;
}
main()
{
foo (&x);
}
would invoke undefined behavior.
Of course our restrict implementation isn't able to capture that (calls
don't have a clique/base which they would get from the "memory" passed
as reference arguments).
So - confirmed. But no easy way out :(
Old idea about special-casing recursive calls also exists but without clear
idea of what would be legal special alias answers here.
[Bug c++/67182] New: Initialising map with disabled copy elision yields unexpected results.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67182
Bug ID: 67182
Summary: Initialising map with disabled copy elision yields
unexpected results.
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vrgo at wp dot pl
Target Milestone: ---
The below code results in creating a map which contains only a single
(incorrect) key-value pair instead of 3.
Code:
#include
#include
struct X
{
int x;
int y;
bool operator<(const X& other) const { return x < other.x; }
};
int main()
{
std::map detailsMap = {
{ X{1, 2}, 7 },
{ X{3, 4}, 7 },
{ X{5, 6}, 7 }
};
std::cout << detailsMap.size() << std::endl;
auto f = *(detailsMap.begin());
std::cout << f.first.x << " " << f.first.y << std::endl;
}
Invocation:
$ g++ prog.cc -Wall -Wextra -I/usr/local/sprout -std=c++11
-fno-elide-constructors
Output:
1
0 0
When I switch off "-fno-elide-constructors" or when I manually add copy and
move constructors to struct X, 'detailsMap' correctly contains 3 given elements
instead of one with some kind of "default" values (X::x = 0 and X::y = 0).
I wasn't able to reproduce this problem with other containers like std::set or
std::vector.
It seems that this behaviour has been introduced in GCC 5.1.0 (I don't have
this problem with GCC 4.9.2).
I have tried it here: http://melpon.org/wandbox/permlink/El3p1eAcZ3azCsFi
[Bug tree-optimization/67175] gcc.dg/vect/trapv-vect-reduc-4.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67175 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from vries at gcc dot gnu.org --- > Created attachment 36164 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36164&action=edit > tentative patch > > Does this patch fix the fail on sparc? It does indeed. I just wonder if it wouldn't be better to skip part of the test based on some target property rather than target triplet. Thanks. Rainer
[Bug fortran/66911] ICE on allocate character with source as a derived type component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66911 --- Comment #6 from Pascal --- Hi, Yes, sorry. I did not state the expected output which is: s:"tt" derived:"tt"
[Bug go/67180] Gccgo does not support MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67180 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #2 from Manuel López-Ibáñez --- (In reply to tsuibin from comment #1) > I added MIPS support to gccgo. > But I don't know how to submit a patch to gccgo I guess in the same way as for any other part of GCC. https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps
[Bug c++/67183] New: Darwin stub vs. non_lazy pointer ordering incompatible with clang assembler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67183
Bug ID: 67183
Summary: Darwin stub vs. non_lazy pointer ordering incompatible
with clang assembler.
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jay.krell at cornell dot edu
Target Milestone: ---
Darwin stub vs. non_lazy pointer ordering incompatible with clang assembler.
Incorrect code results when targeting 32bit older than 10.5.
Request to output in the same order as clang for compatibility -- all stubs
before all non-lazy pointers.
This is really obscure.
It did hit me and I spent a long while debugging it, though still not fully.
There appears to be a bug in the LLVM assembler.
gcc by default does not run it.
i.e.:
gcc -S foo.c
clang foo.s
usually works, but hits a problem here.
It probably only occurs when targeting less than 10.5.
i.e. gcc -mmacosx-version-min=10.4
That switch works with both gcc and clang.
gcc outputs a presumably valid mix of stubs and non-lazy pointers.
You only get the stubs for earlier than 10.5.
clang front end outputs all stubs before all the non-lazy pointers.
gcc outputs them in a jumbled order. Presumably that is ok.
The clang assembler gets confused matching things up when there are non-lazy
pointers before stubs.
The bug is also 32bit specific as 64bit never has stubs.
Here is the bug in action:
jair:~ jay$ cat 1.c
void F1(int);
void F2(int);
extern int i;
void F3() { F1(i); }
void F4() { F2(i); }
jair:~ jay$ $HOME/gcc-5.2.0/bin/gcc -mmacosx-version-min=10.4 -m32 1.c -fPIC
-c -S
jair:~ jay$ clang -c 1.s -m32
jair:~ jay$ otool -tVv 1.o
1.o:
(__TEXT,__text) section
_F3:
pushl %ebp
0001 movl%esp, %ebp
0003 subl$0x8, %esp
0006 calll ___x86.get_pc_thunk.ax
000b leal86-11(%eax), %eax
0011 movl_F3(%eax), %eax
0013 movl_F3(%eax), %eax
0015 subl$0xc, %esp
0018 pushl %eax
0019 calll 0x4c## symbol stub for: _F1
001e addl$0x10, %esp
0021 nop
0022 leave
0023 retl
_F4:
0024 pushl %ebp
0025 movl%esp, %ebp
0027 subl$0x8, %esp
002a calll ___x86.get_pc_thunk.ax
002f leal86-47(%eax), %eax
0035 movl_F3(%eax), %eax
0037 movl_F3(%eax), %eax
0039 subl$0xc, %esp
003c pushl %eax
003d calll 0x51## symbol stub for: _i
0042 addl$0x10, %esp
0045 nop
0046 leave
0047 retl
Where is says "symbol stub for: _i", it should for _F2.
Having gcc output the stubs/non-lazy pointers in the same order as clang
in order to be compatible with the clang assembler might be nice.
For my part, I will either run non-LLVM assembler, or target 10.5 or newer,
at least until I develop or get a patch for gcc to reorder.
Thank you,
- Jay
[Bug c++/65255] std::thread does not work for cross compiling on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65255 --- Comment #6 from Yichao Yu --- Adding `-march=armv7-a` indeed fixes the issue. Thanks. Does this mean that `std::thread` is not supported on armv6? Would be nice to have a warning/error if it is possible to detect this. FWIW, `clang -march=armv6` doesn't have this issue...
[Bug tree-optimization/66799] [6 regression] gcc.dg/vect/pr20122.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66799 --- Comment #2 from Rainer Orth --- Created attachment 36168 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36168&action=edit pr20122.c.133t.vect dump Sorry for the long delay. Dump attached. I happened to do the reghunt on i386-pc-solaris2.10. Nothing special was required when configuring, just --target sparc-sun-solaris2.10. Just in case, here's the full list: configure --with-gmp=/vol/gcc --with-mpfr=/vol/gcc --with-mpc=/vol/gcc --without-ppl --without-cloog --enable-languages=c,c++ --enable-checking=release --disable-libgomp --disable-libquadmath --disable-libssp --disable-libatomic --disable-libitm --disable-libcilkrts --disable-libcc1 --disable-bootstrap --disable-multilib --target sparc-sun-solaris2.10 I've then compiled the testcase like this: cc1 -fpreprocessed pr20122.i -quiet -mcpu=ultrasparc -mvis -O2 -ftree-vectorize -fvect-cost-model=unlimited -fno-common -fdump-tree-vect-details -o pr20122.s Rainer
[Bug go/67180] Gccgo does not support MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67180 --- Comment #3 from Ian Lance Taylor --- Actually, the master sources for gccgo live in a separate repository. The contribution instructions are at https://golang.org/doc/gccgo_contribute.html. Thanks!
[Bug go/67180] Gccgo does not support MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67180 --- Comment #4 from Ian Lance Taylor --- I should add that the files you are changing, in the debug/elf package, are themselves a copy of the files in the master Go repository. It would be very helpful if you could submit a patch for that, following the instructions described at https://golang.org/doc/contribute.html.
[Bug libstdc++/66006] [6 regression] abi_check FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66006 --- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE --- > I have no idea what's going on here: those symbols are in the gcc 5 > libstdc++.so > already, no idea why they are considered incompatible. I see now what's going on here: the two symbols are indeed already present on the gcc 5 branch, but only on Solaris 11, not on Solaris 10. Given that the baselines are currently common to S10 and S11, I couldn't include them to avoid failures on S10. On the GCC 5 branch, all is fine since they only show up as added symbols on S11. OTOH, on mainline, the symbols still get added to the 3.4.21 version, now becoming incompatible and causing the testsuite failure observed. It seems to me that the only way out is to introduce a separate solaris2.11 baseline? Rainer
[Bug c/66098] [5/6 regression] #pragma diagnostic 'ignored' not fully undone by pop for strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66098 Manuel López-Ibáñez changed: What|Removed |Added Keywords||diagnostic Target Milestone|--- |5.3 Summary|#pragma diagnostic |[5/6 regression] #pragma |'ignored' not fully undone |diagnostic 'ignored' not |by pop for strict-overflow |fully undone by pop for ||strict-overflow
[Bug c/66098] [5/6 regression] #pragma diagnostic 'ignored' not fully undone by pop for strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66098 --- Comment #4 from Manuel López-Ibáñez --- Author: manu Date: Tue Aug 11 13:34:00 2015 New Revision: 226780 URL: https://gcc.gnu.org/viewcvs?rev=226780&root=gcc&view=rev Log: gcc/ChangeLog: 2015-08-11 Manuel López-Ibáñez PR c/66098 PR c/66711 * diagnostic.c (diagnostic_classify_diagnostic): Take -Werror into account when deciding what was the command-line status. gcc/testsuite/ChangeLog: 2015-08-11 Manuel López-Ibáñez PR c/66098 PR c/66711 * gcc.dg/pragma-diag-3.c: New test. * gcc.dg/pragma-diag-4.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pragma-diag-3.c trunk/gcc/testsuite/gcc.dg/pragma-diag-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/diagnostic.c trunk/gcc/testsuite/ChangeLog
[Bug c/66711] GCC does not correctly restore diagnostic state after pragma GCC diagnostic pop with -Werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66711 --- Comment #3 from Manuel López-Ibáñez --- Author: manu Date: Tue Aug 11 13:34:00 2015 New Revision: 226780 URL: https://gcc.gnu.org/viewcvs?rev=226780&root=gcc&view=rev Log: gcc/ChangeLog: 2015-08-11 Manuel López-Ibáñez PR c/66098 PR c/66711 * diagnostic.c (diagnostic_classify_diagnostic): Take -Werror into account when deciding what was the command-line status. gcc/testsuite/ChangeLog: 2015-08-11 Manuel López-Ibáñez PR c/66098 PR c/66711 * gcc.dg/pragma-diag-3.c: New test. * gcc.dg/pragma-diag-4.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pragma-diag-3.c trunk/gcc/testsuite/gcc.dg/pragma-diag-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/diagnostic.c trunk/gcc/testsuite/ChangeLog
[Bug c/66098] [5 regression] #pragma diagnostic 'ignored' not fully undone by pop for strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66098 Manuel López-Ibáñez changed: What|Removed |Added Summary|[5/6 regression] #pragma|[5 regression] #pragma |diagnostic 'ignored' not|diagnostic 'ignored' not |fully undone by pop for |fully undone by pop for |strict-overflow |strict-overflow --- Comment #5 from Manuel López-Ibáñez --- Fixed for GCC 6. I'm not planning to seek approval for a backport, but it should be fairly safe and easy to do so.
[Bug sanitizer/67136] sanitizer reports "member access within null pointer" for correct C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67136 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-11 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |5.3 Ever confirmed|0 |1 Severity|major |normal --- Comment #1 from Marek Polacek --- I fixed this on trunk with r226110. This should be safe to backport. (That commit had a follow-up, but I don't think it is needed to fix this bug.)
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #40 from Oleg Endo --- (In reply to Rich Felker from comment #39) > Oleg, do you have rights under your copyright assignment agreement to > dual-license the libgcc part of the patch under GPLv2 so it could be > included in the kernel, and if so, would you be willing to do so? If I understand it correctly, it should be OK. Please contact me directly about this. If possible, please also add the other people who want this to the CC list. > I agree it > would be cleaner for the kernel not to duplicate libgcc code, but getting in > a simple patch to update the code that's there would be a lot easier than > the build-architectural change of using libgcc itself in the kernel, which > is an issue I'd really rather not fight with the kernel developers on if > they disagree. :-) A quick search for "libgcc linux kernel" tells the story about this. Unfortunately, you are right.
[Bug target/58219] [SH] mov.l insn length is wrong on SH2A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58219
--- Comment #1 from Oleg Endo ---
The same applies to FP loads/stores, as this example shows:
float*
test_func_00 (float* p, float* x)
{
float r = 0;
r += *p++;
r += *p++;
*x = r;
return p;
}
fmov.s @r4+,fr2 ! 7 movsf_ie/6 [length = 4]
fldi0 fr1! 8 movsf_ie/3 [length = 2]
mov r4,r0 ! 26 movsi_ie/2 [length = 2]
faddfr2,fr1! 9 addsf3_i[length = 2]
fmov.s @r0+,fr2 ! 10 movsf_ie/6 [length = 4]
faddfr2,fr1! 11 addsf3_i[length = 2]
fmov.s fr1,@r5! 12 movsf_ie/7 [length = 4]
rts/n ! 35 *return_i [length = 4]
[Bug sanitizer/66908] Uninitialized variable when compiled with UBsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908 --- Comment #16 from Marek Polacek --- Author: mpolacek Date: Tue Aug 11 15:46:56 2015 New Revision: 226782 URL: https://gcc.gnu.org/viewcvs?rev=226782&root=gcc&view=rev Log: PR sanitizer/66908 * c-ubsan.c: Include gimplify.h. (ubsan_instrument_division): Unshare OP0 and OP1. (ubsan_instrument_shift): Likewise. * c-c++-common/ubsan/pr66908.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/c-c++-common/ubsan/pr66908.c Modified: branches/gcc-5-branch/gcc/c-family/ChangeLog branches/gcc-5-branch/gcc/c-family/c-ubsan.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug sanitizer/67136] sanitizer reports "member access within null pointer" for correct C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67136 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Marek Polacek --- Fixed on GCC 5 as well.
[Bug c++/67147] [concepts] ICE on checking concept with default template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67147 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-11 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c/67146] Wchkp is not documented in invoke.texi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67146 Marek Polacek changed: What|Removed |Added Keywords||documentation Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-11 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- True.
[Bug c/67132] gcc -D__WCHAR_TYPE__='unsigned int' should not complain about built-in types redefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67132 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- I think the warning is desirable... Use -Wno-pointer-sign or fix the program, I'd say.
[Bug libgomp/67141] wrong libgomp mutex initialisation order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67141 xantares09 at hotmail dot com changed: What|Removed |Added CC||xantares09 at hotmail dot com --- Comment #1 from xantares09 at hotmail dot com --- Created attachment 36169 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36169&action=edit call initialize_env before goacc_host_init I can reproduce here: err:module:attach_process_dlls "libgomp-1.dll" failed to initialize, aborting Mattias is totally right: if i assign a higher initialization priority to env.c:initialize_env than oacc-host.c:goacc_host_init the dll is correctly initialized the patch may not be ok, but you get the idea
[Bug tree-optimization/67153] [5/6 Regression] integer optimizations 53% slower than std::bitset<>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153 --- Comment #6 from ncm at cantrip dot org --- It seems worth adding that the same failure occurs without "-march=native".
[Bug target/67004] valgrind error in recog_memoized & shorten_branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67004 Uroš Bizjak changed: What|Removed |Added Target||x86 Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #3 from Uroš Bizjak --- Fixed.
[Bug c++/67184] New: Missed optimization with C++11 final specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67184
Bug ID: 67184
Summary: Missed optimization with C++11 final specifier
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gpderetta at gmail dot com
Target Milestone: ---
struct V {
virtual void foo();
};
struct wV final : V {
};
struct oV final : V {
void foo();
};
void call(V& x)
{
x.foo();
}
void call(wV& x)
{
x.foo();
}
void call(oV& x)
{
x.foo();
}
# compile with g++ -O3 -std=c++11
gcc 5.1 and 5.2 on x86-64 generate:
call(V&):
movq(%rdi), %rax
jmp *(%rax)
call(wV&):
movq(%rdi), %rax
jmp *(%rax)
call(oV&):
jmp oV::foo()
I would expect call(wV&) to generate the same code as call(oV&).
FWIW Clang generates the expected code since about 3.5.
[Bug target/66954] function multiversioning fails for target "aes"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66954 --- Comment #4 from uros at gcc dot gnu.org --- Author: uros Date: Tue Aug 11 17:53:41 2015 New Revision: 226784 URL: https://gcc.gnu.org/viewcvs?rev=226784&root=gcc&view=rev Log: libgcc/ChangeLog: PR target/66954 * config/i386/cpuinfo.c (enum processor_features): Add FEATURE_PCLMUL. (get_available_features): Handle FEATURE_PCLMUL. gcc/ChangeLog: PR target/66954 * config/i386/i386.c (get_builtin_code_for_version): Add P_PCLMUL to enum feature_priority and feature_list. (fold_builtin_cpu): Add F_PCLMUL to enum processor_features and isa_names_table. gcc/testsuite/ChangeLog: PR target/66954 * g++.dg/ext/mv25.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/mv25.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog trunk/libgcc/ChangeLog trunk/libgcc/config/i386/cpuinfo.c
[Bug c++/65255] std::thread does not work for cross compiling on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65255 --- Comment #7 from Jonathan Wakely --- It's supported fine, but you need to compile your code that uses std::thread so it is compatible with the libstdc++.so library you link to. If libstdc++ is compiled to use atomic operations in shared_ptr then you need to compile your code so it also uses atomics. If libstdc++ is compiled to use mutexes in shared_ptr then you need to compile your code the same way.
[Bug c++/67185] New: [concepts] Link error on ODR-use of constexpr constrained variable template partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67185
Bug ID: 67185
Summary: [concepts] Link error on ODR-use of constexpr
constrained variable template partial specialization
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Created attachment 36170
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36170&action=edit
Test case
r226750 compiles this program compiles correctly:
template
concept bool C = false;
template
constexpr bool trait = false;
template
constexpr bool trait = true;
const bool& f() { return trait; }
int main() {}
since it uses the base template, but not this one:
template
concept bool C = true;
template
constexpr bool trait = false;
template
constexpr bool trait = true;
const bool& f() { return trait; }
int main() {}
The error is:
~/gcc6-r226750/bin/g++ -std=gnu++1z foo2.cpp
/tmp/ccfAOK5N.o: In function `f()':
foo2.cpp:(.text+0x5): undefined reference to `trait'
collect2: error: ld returned 1 exit status
Inspection of the assembly output (target is Linux x64) shows that the first
program uses the symbol "_Z5traitIiE" for "trait" and the second the
symbol "_ZL5trait". I suspect this discrepancy is the crux of the problem.
[Bug c++/65255] std::thread does not work for cross compiling on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65255 --- Comment #8 from Jonathan Wakely --- I have a patch for std::thread which would mean it doesn't use shared_ptr, so this wouldn't be a problem even if you don't use the same arm version.
[Bug c++/65255] std::thread does not work for cross compiling on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65255 Yichao Yu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #9 from Yichao Yu --- Thanks for the explaination. > I have a patch for std::thread which would mean it doesn't use shared_ptr, so > this wouldn't be a problem even if you don't use the same arm version. I guess this might be the implementation detail that causes this to not happen for clang but I agree in general finding the right version of library at runtime is more of a distribution / system manager problem.
[Bug c++/67184] Missed optimization with C++11 final specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67184 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-11 CC||hubicka at gcc dot gnu.org, ||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- Confirmed. Adding CC.
[Bug tree-optimization/67153] [5/6 Regression] integer optimizations 53% slower than std::bitset<>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153 --- Comment #7 from Uroš Bizjak --- (In reply to ncm from comment #6) > It seems worth adding that the same failure occurs without "-march=native". Can you experiment a bit with -mno-bmi and/or -mno-bmi2 compile options?
[Bug tree-optimization/67153] [5/6 Regression] integer optimizations 53% slower than std::bitset<>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153 --- Comment #8 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #7) > Can you experiment a bit with -mno-bmi and/or -mno-bmi2 compile options? Also, perf is able to record execution profiles, it will help you find hot spots.
[Bug middle-end/66565] Problems and limitation GCC cost metrics and ways to improve the situation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66565 --- Comment #2 from David Edelsohn --- The high-level consensus at the GNU Cauldron 2015 GCC Cost Model BoF is: 1) Create gimple_costs() instead of creating potentially invalid fragments to query rtx_costs(). 2) Cost models can utilize GCC Pass phase to set expectations for optimization changes by later passes. 3) Cost models should be queried for relative comparisons of the potential instruction sequences, not for comparisons against magic constants.
[Bug target/29256] [4.9/5/6 regression] loop performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256 --- Comment #56 from Bill Schmidt --- (In reply to Bill Schmidt from comment #53) > I'm not a fan of a tree-level unroller. It's impossible to make good > decisions about unroll factors that early. But your second approach sounds > quite promising to me. I would be willing to soften this statement. I think that an early unroller might well be a profitable approach for most systems with large caches and so forth, where if the unrolling heuristics are not completely accurate we are still likely to make a reasonably good decision. However, I would expect to see ports with limited caches/memory to want more accurate control over unrolling decisions. So I could see allowing ports to select between a GIMPLE unroller and an RTL unroller (I doubt anybody would want both). In general it seems like PowerPC could benefit from more aggressive unrolling much of the time, provided we can also solve the related IVOPTS problems that cause too much register spill. I may have an interest in working on a GIMPLE unroller, depending on how quickly I can complete or shed some other projects...
[Bug middle-end/60586] [Cilk+] Parameters evaluation happens inside spawn worker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60586 Arch D. Robison changed: What|Removed |Added CC||arch.robison at hotmail dot com --- Comment #1 from Arch D. Robison --- Created attachment 36171 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36171&action=edit Another demonstration of the bug Unpack and run "make" to build and run it. Requires routine "usleep" from . When compiled correctly, it should run without comment. Otherwise, as with gcc 5.2.0, it will report errors. E.g., here is a sample session: $ make g++ -O0 -std=c++11 -fcilkplus harness.cpp -c g++ -O0 -std=c++11 -fcilkplus test.cpp -c g++ -O0 -std=c++11 -fcilkplus harness.o test.o ./a.out ERROR: f.val=3, should be 2 ERROR: f.val=6, should be 3 make: *** [all] Aborted
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #41 from Segher Boessenkool --- On the other hand, there are quite a few archs (more modern ones mostly) where the Linux kernel uses the real libgcc. And the SH kernel maintainers won't complain anyway (SH is orphaned).
[Bug c/57157] Poor optimization of portable rotate idiom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57157 Jeffrey Walton changed: What|Removed |Added CC||noloader at gmail dot com --- Comment #6 from Jeffrey Walton --- (In reply to Jakub Jelinek from comment #4) > Created attachment 30075 [details] > /tmp/gcc49-pr57157.patch > > Untested tiny i386 improvement, instead of roll $31, %eax we can emit > rorl %eax which is shorter. Forgive my ignorance... Why not put the shift amount in %ecx, %cx or %cl? The x86 processor will only use the low-order 5-bits (low order 6-bits for x86_64). That means you get the mask for free. With a free mask, you don't even have to worry about the ranges in C/C++ or the assembler's "I" or "J" constraints.
[Bug other/67186] New: Libiberty fails to demangle C++ function name if clone suffix contains digit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67186 Bug ID: 67186 Summary: Libiberty fails to demangle C++ function name if clone suffix contains digit Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: warieth at gmail dot com Target Milestone: --- Created attachment 36172 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36172&action=edit patch Using g++ (GCC) 5.2.0 on x86_64 and target attributes the generated funtion in object code can't be demangled if the target contains digits (like arch_core2, ssse3, sse4.2). The attachment contains a patch for this. https://gcc.gnu.org/wiki/FunctionMultiVersioning
[Bug other/67186] Libiberty fails to demangle C++ function name if clone suffix contains digit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67186 --- Comment #1 from David Kovacs --- Created attachment 36173 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36173&action=edit test case
[Bug c/67132] gcc -D__WCHAR_TYPE__='unsigned int' should not complain about built-in types redefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67132 --- Comment #2 from Giacomo Tesio --- The warning about signedness if perfectly fine. What I'd like to be able to do (without warnings) is to redefine tree built-in types and constants at the command line. Since it already works, the only issue is that GCC complains because his own built-ins are already been defined at command line. But from my tests, the command gcc -D__WCHAR_TYPE__='unsigned int' -D__WCHAR_MAX__=4294967295U -D__WCHAR_MIN__=0 hello.c -o hello turns all L"" notations in an unsigned int * (instead of the int * they are by default). In other terms: in the expression Rune *s = L"Άρχιμήδης"; I don't want to suppress the warning about signedness, I want that the right end side of the expression is desugared as an array of unsigned int. And I want to be able to do that with options at the gcc command line. And looks like it already works! But, gcc complains about the redefinition of its own internal types. These are the warnings that I want to suppress, not those about the signedness of the assigment (that are correct and useful).
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #42 from Oleg Endo --- (In reply to Segher Boessenkool from comment #41) > On the other hand, there are quite a few archs (more modern ones > mostly) where the Linux kernel uses the real libgcc. If this is the case (could you please name a few of those archs just for reference?) ... > And the SH > kernel maintainers won't complain anyway (SH is orphaned). ... then this issue now is a very good opportunity to fix the actual problem (remove libgcc code from the kernel and link it against the proper libgcc).
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #43 from Segher Boessenkool --- The archs that already use the real libgcc are arc, cris, hexagon, m32r, nios2, openrisc, parisc, xtensa. grep -w LIBGCC ~/src/kernel/arch/*/Makefile
[Bug driver/67187] New: Not able to build GMP for Mac OS Yosemite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67187 Bug ID: 67187 Summary: Not able to build GMP for Mac OS Yosemite Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: jai.sharma3521 at gmail dot com Target Milestone: --- Created attachment 36174 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36174&action=edit Logs Details Hi, I am trying to build GMP library for iOS on Mac OS Yosemite(10.10.2).My Xcode verison is 6.1.1 .I have checked everything like command line tools but everytime I try build build GMP getting some error.I have attached the Logs file which contains the error I am getting. I followed this link https://solarianprogrammer.com/2015/05/01/compiling-gcc-5-mac-os-x/ to install GCC. Xcode is Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Please help me out to solve this problem
[Bug driver/67187] Not able to build GMP for Mac OS Yosemite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67187 Marc Glisse changed: What|Removed |Added Severity|major |normal --- Comment #1 from Marc Glisse --- Where do you see an error? I can only find warnings in that config.log file.
[Bug testsuite/67175] gcc.dg/vect/trapv-vect-reduc-4.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67175 --- Comment #3 from vries at gcc dot gnu.org --- Author: vries Date: Wed Aug 12 05:50:55 2015 New Revision: 226800 URL: https://gcc.gnu.org/viewcvs?rev=226800&root=gcc&view=rev Log: Fix vect/trapv-vect-reduc-4.c for sparc 2015-08-12 Tom de Vries PR testsuite/67175 * gcc.dg/vect/trapv-vect-reduc-4.c: Add reduction detection scan. Handle absence of vector min/max for sparc. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/trapv-vect-reduc-4.c
[Bug driver/67187] Not able to build GMP for Mac OS Yosemite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67187
Jai changed:
What|Removed |Added
Version|unknown |5.1.0
--- Comment #2 from Jai ---
(In reply to Marc Glisse from comment #1)
> Where do you see an error? I can only find warnings in that config.log file.
Hi
Thanks for replying
I am talking about this
Applications/Xcode.app/Contents/Developer/usr/bin/make install-recursive
Making install in tests
Making install in .
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
Making install in devel
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
Making install in mpn
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
Making install in mpz
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
Making install in mpq
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
Making install in mpf
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
Making install in rand
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
Making install in misc
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
Making install in cxx
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
Making install in mpn
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
Making install in mpz
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
Making install in mpq
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
Making install in mpf
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
Making install in printf
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
Making install in scanf
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
Making install in rand
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
Making install in cxx
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
Making install in demos
Making install in calc
/Applications/Xcode.app/Contents/Developer/usr/bin/make install-am
make[5]: Nothing to be done for `install-exec-am'.
make[5]: Nothing to be done for `install-data-am'.
Making install in expr
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
Making install in tune
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
Making install in doc
make[3]: Nothing to be done for `install-exec-am'.
../../install-sh -c -d '/usr/gcc-5.1.0/share/info'
/usr/bin/install -c -m 644 ../../doc/gmp.info ../../doc/gmp.info-1
../../doc/gmp.info-2 '/usr/gcc-5.1.0/share/info'
install-info --info-dir='/usr/gcc-5.1.0/share/info'
'/usr/gcc-5.1.0/share/info/gmp.info'
../install-sh -c -d '/usr/gcc-5.1.0/lib'
/bin/sh ./libtool --mode=install /usr/bin/install -c libgmp.la libgmpxx.la
'/usr/gcc-5.1.0/lib'
libtool: install: /usr/bin/install -c .libs/libgmp.10.dylib
/usr/gcc-5.1.0/lib/libgmp.10.dylib
libtool: install: (cd /usr/gcc-5.1.0/lib && { ln -s -f libgmp.10.dylib
libgmp.dylib || { rm -f libgmp.dylib && ln -s libgmp.10.dylib libgmp.dylib; };
})
libtool: install: /usr/bin/install -c .libs/libgmp.lai
/usr/gcc-5.1.0/lib/libgmp.la
libtool: install: /usr/bin/install -c .libs/libgmpxx.4.dylib
/usr/gcc-5.1.0/lib/libgmpxx.4.dylib
libtool: install: (cd /usr/gcc-5.1.0/lib && { ln -s -f libgmpxx.4.dylib
libgmpxx.dylib || { rm -f libgmpxx.dylib && ln -s libgmpxx.4.dylib
libgmpxx.dylib; }; })
libtool: install: /usr/bin/install -c .libs/libgmpxx.lai
/usr/gcc-5.1.0/lib/libgmpxx.la
libtool: install: /usr/bin/install -c .libs/libgmp.a
/usr/gcc-5.1.0/lib/libgmp.a
libtool: install: chmod 644 /usr/gcc-5.1.0/lib/libgmp.a
libtool: install: ranlib /usr/gcc-5.1.0/lib/libgmp.a
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
file: /usr/gcc-5.1.0/lib/libgmp.a(mp_clz_tab.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
file: /usr/gcc-5.1.0/lib/libgmp.a(obprintf.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
file:
[Bug driver/67187] Not able to build GMP for Mac OS Yosemite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67187 --- Comment #3 from Marc Glisse --- (In reply to Jai from comment #2) > I am talking about this [snip wall of text with some warnings but no error as far as I can see] > How to remove this issue? Again, what issue?
[Bug driver/67187] Not able to build GMP for Mac OS Yosemite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67187 --- Comment #4 from Jai --- Created attachment 36175 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36175&action=edit Config file While building GMP6.0.0 Attached is the config while when I try to build GMP.There is Clang Error.
[Bug testsuite/67175] gcc.dg/vect/trapv-vect-reduc-4.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67175 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from vries at gcc dot gnu.org --- Patch committed, marking resolved-fixed
[Bug testsuite/67175] gcc.dg/vect/trapv-vect-reduc-4.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67175 --- Comment #4 from vries at gcc dot gnu.org --- (In reply to r...@cebitec.uni-bielefeld.de from comment #2) > I just wonder if it wouldn't be better to skip part of > the test based on some target property rather than target triplet. > Submitted '[RFC] Add check_effective_target_vect_min_max' at https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00567.html .
[Bug driver/67187] Not able to build GMP for Mac OS Yosemite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67187 --- Comment #5 from Jai --- (In reply to Marc Glisse from comment #3) > (In reply to Jai from comment #2) > > I am talking about this > > [snip wall of text with some warnings but no error as far as I can see] > > > How to remove this issue? > > Again, what issue? See the Config.log you can see the Clang error. ndefined symbols for architecture x86_64: "_main", referenced from: implicit entry/start for main executable ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)
[Bug driver/67187] Not able to build GMP for Mac OS Yosemite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67187 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Andrew Pinski --- This is not a GCC bug as GCC does not control either clang or GMP.
[Bug c++/67183] Darwin stub vs. non_lazy pointer ordering incompatible with clang assembler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67183 --- Comment #1 from Jay --- It turns out, this looks easy to "fix" on the gcc side. See machopic_finish. Have it run two traversla instead of one. The first editing stubs, the second non-lazy pointers.
