https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63783
--- Comment #2 from Oleg Endo ---
Thanks for tracing this down. Yes, it looks like a sh_treg_combine bug. I
will have a look at it, but probably only in 2 weeks from now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773
--- Comment #10 from howarth at bromo dot med.uc.edu ---
Regression testing on x86_64-apple-darwin14 at
https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00806.html.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63784
H.J. Lu changed:
What|Removed |Added
CC||markus at trippelsdorf dot net
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63784
--- Comment #3 from H.J. Lu ---
This part:
@@ -4451,7 +4452,7 @@ _LT_EOF
if $LD --help 2>&1 | $EGREP ': supported targets:.* elf' > /dev/null \
&& test "$tmp_diet" = no
then
-tmp_addflag=
+tmp_addflag=' $pic_flag'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63784
--- Comment #2 from H.J. Lu ---
We have a few choices:
1. Build libcc1 with LTO when GCC is configured with
"--with-build-config=bootstrap-lto". Or
2. Teach libtool to always add -fPIC when linking shared
object to support static archive compil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63784
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63787
Bug ID: 63787
Summary: [5 Regression] profiledbootstrap failure with
bootstrap-lto
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63786
Bug ID: 63786
Summary: crash on argument pack in switch case
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63783
Kazumoto Kojima changed:
What|Removed |Added
Target||sh*-*-*
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018
Francois-Xavier Coudert changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63785
Bug ID: 63785
Summary: [5.0 regression] FAIL:
gfortran.dg/transfer_simplify_2.f90 -O0 (internal
compiler error)
Product: gcc
Version: 5.0
Status: U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43821
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926
--- Comment #10 from Andre Netzeband ---
Once again the question: The original error report is around 1,5 years old. I
can hardly believe that there has been absolutely no progress so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56542
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63784
Bug ID: 63784
Summary: [5 Regression] profiledbootstrap failure with
bootstrap-lto
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63765
--- Comment #5 from David Edelsohn ---
If _XOPEN_SOURCE is removed from thr.c completely, the testsuite results revert
to 1 failure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45486
Francois-Xavier Coudert changed:
What|Removed |Added
Keywords||wrong-code
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30517
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31142
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63783
Bug ID: 63783
Summary: gcc-4.9: Miscompilation of boolean negation on SH4
using -O2
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42951
--- Comment #3 from Francois-Xavier Coudert ---
*** Bug 47816 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47816
Francois-Xavier Coudert changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63782
Bug ID: 63782
Summary: avoid implicit declaration warning for incompatible
builtin implicit declaration
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
--- Comment #11 from Francois-Xavier Coudert ---
(In reply to howarth from comment #10)
> So the compiler will emit the ___cxa_tm_cleanup to resolve the undefined
> symbol in libitm?
No, that symbol is in libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60886
--- Comment #1 from Manuel López-Ibáñez ---
It seems Clang fans peruse GCC's bugzilla to showcase Clang vs GCC in their
talks. This exact example was used in a talk by Samsumg at LinuxCon Europe:
http://events.linuxfoundation.org/sites/events/fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26553
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
--- Comment #10 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #9)
> (In reply to Francois-Xavier Coudert from comment #8)
> > As far as I understand, libitm is supposed to be used with either C or C++.
> > As such,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
--- Comment #9 from Iain Sandoe ---
(In reply to Francois-Xavier Coudert from comment #8)
> As far as I understand, libitm is supposed to be used with either C or C++.
> As such, it contains some C++ code which requires libstdc++, but doesn't
> l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63716
--- Comment #4 from cordlandwehr at kde dot org ---
Thanks, I could workaround this problem by fiddling a little bit with includes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
--- Comment #7 from howarth at bromo dot med.uc.edu ---
(In reply to howarth from comment #6)
> Okay, I see the missing linkage on libstdc++ is intentional...
>
> # Force link with C, not C++. For now, while we're using C++ we don't
> # want or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
--- Comment #6 from howarth at bromo dot med.uc.edu ---
Okay, I see the missing linkage on libstdc++ is intentional...
# Force link with C, not C++. For now, while we're using C++ we don't
# want or need libstdc++.
libitm_la_DEPENDENCIES = $(lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49275
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52226
Francois-Xavier Coudert changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
--- Comment #5 from howarth at bromo dot med.uc.edu ---
The problematic code in eh_cpp.cc appears to be...
#if !defined (HAVE_ELF_STYLE_WEAKREF)
void *__cxa_allocate_exception (size_t) { return NULL; }
void __cxa_throw (void *, void *, void *) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229
--- Comment #22 from Francois-Xavier Coudert ---
(In reply to Iain Sandoe from comment #21)
> in short (2) is very definitely "works for me"
For me too: I regularly build darwin-to-mingw-w64 cross compilers, with no
problem at all. But there wer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
--- Comment #4 from howarth at bromo dot med.uc.edu ---
Attached bzip2 of eh_cpp.ii created using...
# /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/xg++
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/ -nostdinc++
-nostdinc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
--- Comment #3 from howarth at bromo dot med.uc.edu ---
Created attachment 33923
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33923&action=edit
bzip2 compressed eh_cpp.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229
--- Comment #21 from Iain Sandoe ---
(In reply to Francois-Xavier Coudert from comment #20)
> This PR appears to report two different issues:
> 1. cross-compiler targeting Darwin
cross-compilers targeting Darwin <= 9 are possible using odcctoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
--- Comment #2 from howarth at bromo dot med.uc.edu ---
The missing linkage on libstdc++ would be solved by making sure that the
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/xg++ compiler is used
to link libitm rather than the current
/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28910
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28913
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
--- Comment #1 from howarth at bromo dot med.uc.edu ---
Note that this is the only shared library in gcc trunk that produces undefined
symbols on darwin when "-undefined dynamic_lookup" is removed to expose them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
Bug ID: 63781
Summary: potential linkage issue with libitm.1.dylib
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libitm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43099
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35378
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63761
--- Comment #3 from thopre01 at gcc dot gnu.org ---
I got a local patch that makes this code compile without error and I can build
gcc with this patch. I'm now going to run the testsuite, add some more comments
and try to make a reduced testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #36 from Manuel López-Ibáñez ---
Latest patch: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00663.html
Joseph pointed out that it does not handle escape sequences. The only solution
I can think of is to open the file and re-parse th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63736
Jonathan Wakely changed:
What|Removed |Added
Known to work||4.9.2, 5.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63780
--- Comment #2 from Jonathan Wakely ---
This is nothing to do with libstdc++:
int main() {
int n;
double x = 3419, m = 360;
double y = __builtin_remainder(x, m);
double z = __builtin_remquo(x, m, &n);
__builtin_printf("result %.0f %.0f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792
--- Comment #20 from Iain Sandoe ---
Unofficially (but after chatting with a couple of folks who know):
"It should be assumed that depending on /usr/{include,lib} is unreliable".
"The RightWay(™) for the system is deemed to be finding a suitab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62132
--- Comment #11 from Iain Sandoe ---
(In reply to Yury Gribov from comment #10)
> (In reply to Dominique d'Humieres from comment #9)
> > Per comments 6 and 7 I have tried
> > ...
> > but it does not fix the failures. What am I misunderstanding?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651
--- Comment #7 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #5)
> (In reply to Francois-Xavier Coudert from comment #4)
> > (In reply to Dominique d'Humieres from comment #3)
> > > Does it means that 'id' should b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651
--- Comment #6 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #5)
> (In reply to Francois-Xavier Coudert from comment #4)
> > (In reply to Dominique d'Humieres from comment #3)
> > > Does it means that 'id' should b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651
--- Comment #5 from Iain Sandoe ---
(In reply to Francois-Xavier Coudert from comment #4)
> (In reply to Dominique d'Humieres from comment #3)
> > Does it means that 'id' should be replaced with 'instancetype' in failing
> > tests? What about the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651
--- Comment #4 from Francois-Xavier Coudert ---
(In reply to Dominique d'Humieres from comment #3)
> Does it means that 'id' should be replaced with 'instancetype' in failing
> tests? What about the gnu-runtime?
No, we need to make the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651
--- Comment #3 from Dominique d'Humieres ---
(In reply to Francois-Xavier Coudert from comment #2)
> > I suppose as a first approach, we could make it equivalent to id.
>
> Not really, apparently: the answer there gives a quite complete descripti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63780
--- Comment #1 from Charles Karney ---
Created attachment 33922
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33922&action=edit
Assembly file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63780
Bug ID: 63780
Summary: std::remquo returns wrong quotient
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63748
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
De
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54780
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=346
Manuel López-Ibáñez changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44685
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63776
--- Comment #3 from Tom Straub ---
Hi Tim,
OOPS! The versions used were Boost REGEX 1.55.0 and ICU 52. Got the versions
mixed up in my head.
Tom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63776
--- Comment #2 from Tom Straub ---
Hi Tim,
Okay, a program very similar to this using the Boost REGEX library and ICU 4.55
works just fine with this.
According to my understanding, the "char" data type and "std::string" classes
were specificall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54232
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773
--- Comment #9 from howarth at bromo dot med.uc.edu ---
(In reply to howarth from comment #8)
Successfully bootstrapped with same configure options at same revision on...
x86_64-apple-darwin11 against Xcode 4.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63775
Tim Shen changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment #1 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63779
Bug ID: 63779
Summary: g++ 4.9 generates invalid object provoking a GOT
relative relocation must reference a local symbol
linker error on SunOS
Product: gcc
Versi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61391
Arseny Solokha changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63747
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63776
Tim Shen changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment #1 fro
75 matches
Mail list logo
