https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68195
Bug ID: 68195
Summary: gcc//ld produces invalid ABI results (cxx11 problem?)
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68194
Bug ID: 68194
Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49454
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49429
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68083
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68083
--- Comment #7 from Alexandre Oliva ---
Author: aoliva
Date: Tue Nov 3 00:30:07 2015
New Revision: 229690
URL: https://gcc.gnu.org/viewcvs?rev=229690&root=gcc&view=rev
Log:
[PR68083] don't introduce undefined behavior in ifcombine
The ifcombin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68193
Bug ID: 68193
Summary: _Generic -Woverflow false alarm
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070
--- Comment #25 from Dominique d'Humieres ---
The regression (ICE) is caused by revision r188692 (pr53642). If I apply the
following patch
--- ../_clean/gcc/fortran/trans-expr.c 2015-10-29 17:11:18.0 +0100
+++ gcc/fortran/trans-expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68182
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68164
W E Brown changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68190
--- Comment #6 from Nik Bougalis ---
I don't follow why an auto return is used, instead of simply
iterator/const_iterator which is the required return value per the
documentation I've read.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68190
--- Comment #5 from Markus Trippelsdorf ---
710 { return _M_t._M_find_tr(__x); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68190
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67736
--- Comment #7 from Steve Ellcey ---
Author: sje
Date: Mon Nov 2 21:08:02 2015
New Revision: 229678
URL: https://gcc.gnu.org/viewcvs?rev=229678&root=gcc&view=rev
Log:
2015-11-02 Steve Ellcey
2015-10-23 Steve Ellcey
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67736
--- Comment #6 from Steve Ellcey ---
Author: sje
Date: Mon Nov 2 21:04:33 2015
New Revision: 229677
URL: https://gcc.gnu.org/viewcvs?rev=229677&root=gcc&view=rev
Log:
2015-11-02 Steve Ellcey
Backport from mainline
2015-10-23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67657
--- Comment #17 from John Paul Adrian Glaubitz ---
I have scheduled a rebuild of libjpeg-turbo now. The package is now waiting for
the next free buildd. Please have a look at the package log here [1] once any
of the buildds has made a build attem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67716
--- Comment #23 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #22)
> I think we can close this as fixed.
Yes, I can confirm libraw now builds fine. Full build log available at [1].
Adrian
> [1]
> https://buildd.debian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65251
--- Comment #5 from John Paul Adrian Glaubitz ---
Hmm, the build now failed due to "out of memory" apparently [1]:
[ 7%] Building CXX object
libs/network/src/CMakeFiles/cppnetlib-uri.dir/uri/uri.cpp.o
cd /<>/cpp-netlib-0.11.2+dfsg1/obj-sh4-linu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68192
David Edelsohn changed:
What|Removed |Added
Target||powerpc-ibm-aix*
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68190
--- Comment #3 from Daniel Krügler ---
(In reply to Markus Trippelsdorf from comment #1)
Markus, could you please elaborate on your reference to LWG 103? At the moment
I see no relation to the code example. With acceptance of
http://www.open-st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68192
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68192
Bug ID: 68192
Summary: AIX libstdc++ TLS symbols not exported
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68191
Bug ID: 68191
Summary: s390x Linux Split Stacks support
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68190
--- Comment #2 from Howard Hinnant ---
LWG 103 isn't the issue.
http://melpon.org/wandbox/permlink/MzOWaFpvFRtgaa7t
C::iterator is std::_Rb_tree_const_iterator
C::const_iterator is std::_Rb_tree_const_iterator
C::find(1u) returns std::_R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68189
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68190
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68190
Bug ID: 68190
Summary: iterator mix up with set::find and heterogenous lookup
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68189
Bug ID: 68189
Summary: wrong code at -Os and above on x86_64-linux-gnu
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68188
Bug ID: 68188
Summary: Ambiguous code gets compiled successfully when class
and its namespace have the same name
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68178
--- Comment #7 from Rich Felker ---
I agree that the PC-relative relocation in the literal pool is acceptable and
what the compiler should be doing. However, the form of the expression the
compiler puts in the assembly output does not actually ge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68178
--- Comment #6 from Richard Earnshaw ---
Oh, and another point; since this is a function symbol, not a data symbol, it
can't be subject to a copy relocation at run time, so even protected symbols
should be acceptable here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68178
--- Comment #5 from Richard Earnshaw ---
This particular case is a very specific situation.
A definition of foo is guaranteed to exist (you've provided one); but it can be
overridden.
The definition (due to the use of hidden) has to exist in th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68187
Bug ID: 68187
Summary: Poor error message from -Wmisleading-indentation on
glibc's ../stdlib/strtol_l.c
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68185
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67922
--- Comment #3 from Yegor Derevenets ---
A small correction. A colleague of mine bothered to read the source code of
libc++ and noticed that its implementation of clear() method also generally
takes time, linear in the number of buckets. This was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68178
--- Comment #4 from Rich Felker ---
Well the binutils side seems to think it's a GCC bug to generate relative
address expressions like this; at least that's the response I got when I
reported it for sh. See the binutils bug linked in the original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68186
Bug ID: 68186
Summary: Using public base member function privately prevents
derived classes using base member function
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68185
Bug ID: 68185
Summary: wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029
--- Comment #6 from Manuel López-Ibáñez ---
(In reply to Jiří Engelthaler from comment #5)
> I have tested GCC with reverted r228094 and there is not problem reported by
> this bug.
> I'm asking someone with rights to reopen the bug 67640 and lin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68178
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68184
Bug ID: 68184
Summary: Exception from a virtual function does not get caught
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66609
--- Comment #11 from Rich Felker ---
FYI a workaround for this and similar bugs, for users who are unable to
upgrade, is to always use -ffunction-sections -fdata-sections. This inhibits
the assembler's "optimization" differences between symbols s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68178
--- Comment #2 from Rich Felker ---
FYI a workaround for this and similar bugs, for users who are unable to upgrade
once it's fixed, is to always use -ffunction-sections -fdata-sections. This
inhibits the assembler's "optimization" differences be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68183
Bug ID: 68183
Summary: Using Serial communication stream lose packets
somtimes, file OK
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68182
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68182
--- Comment #1 from alalaw01 at gcc dot gnu.org ---
Created attachment 36636
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36636&action=edit
Preprocessed source (compressed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68182
Bug ID: 68182
Summary: ICE in reorder_basic_blocks_simple building
libitm/beginend.cc
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68181
Bug ID: 68181
Summary: djgpp: minor linker invocation issues
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: driver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029
--- Comment #5 from Jiří Engelthaler ---
(In reply to Manuel López-Ibáñez from comment #4)
> (In reply to Jiří Engelthaler from comment #3)
> > (In reply to Manuel López-Ibáñez from comment #2)
> > > What does -### show for the call to cc1 ? My c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67929
--- Comment #11 from ktkachov at gcc dot gnu.org ---
(In reply to Christophe Lyon from comment #7)
> This is because check_effective_target_arm_vfp3_ok only checks whether a
> *compilation* with -mfloat-abi=soffp works, and does not check that a l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68180
Bug ID: 68180
Summary: [ICE] at cp/constexpr.c:2768 in initializing __vector
in a loop
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67794
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029
--- Comment #4 from Manuel López-Ibáñez ---
(In reply to Jiří Engelthaler from comment #3)
> (In reply to Manuel López-Ibáñez from comment #2)
> > What does -### show for the call to cc1 ? My commit r228094 to opts-common.c
> > should have fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67794
--- Comment #13 from Martin Jambor ---
Author: jamborm
Date: Mon Nov 2 14:04:19 2015
New Revision: 229666
URL: https://gcc.gnu.org/viewcvs?rev=229666&root=gcc&view=rev
Log:
2015-11-02 Martin Jambor
PR tree-optimization/67794
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029
--- Comment #3 from Jiří Engelthaler ---
(In reply to Manuel López-Ibáñez from comment #2)
> What does -### show for the call to cc1 ? My commit r228094 to opts-common.c
> should have fixed this.
$ gcc -fdiagnostics-color=never a.c -###
cc1.exe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67929
--- Comment #10 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Mon Nov 2 12:29:31 2015
New Revision: 229659
URL: https://gcc.gnu.org/viewcvs?rev=229659&root=gcc&view=rev
Log:
Move gcc.target/arm/pr67929_1.c test to execute.exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67929
--- Comment #9 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Mon Nov 2 12:26:39 2015
New Revision: 229658
URL: https://gcc.gnu.org/viewcvs?rev=229658&root=gcc&view=rev
Log:
Move gcc.target/arm/pr67929_1.c test to execute.exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67929
--- Comment #8 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Mon Nov 2 12:23:36 2015
New Revision: 229657
URL: https://gcc.gnu.org/viewcvs?rev=229657&root=gcc&view=rev
Log:
Move gcc.target/arm/pr67929_1.c test to execute.exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68176
--- Comment #3 from Nix ---
I haven't tested that yet, so I wasn't willing to commit to it. It seems very
likely though.
(I wasn't sure of protocol, or I'd have put you in the Cc list as the author of
the fix for bug 65550, but I was afraid that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56118
--- Comment #7 from Richard Biener ---
(In reply to Marc Glisse from comment #4)
> #include
> __m128d f(){
> __m128d r;
> r[0]=1;
> r[1]=2;
> return r;
> }
>
> Currently, SLP vectorizes it with -fvect-cost-model=unlimited, but not by
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070
--- Comment #24 from Dominique d'Humieres ---
The test in comment 23 looks like a duplicate of pr50221.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56118
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68179
--- Comment #1 from Troy ---
Command line to build sample code:
gnatmake -gnat12 -gnatE -gnatf -gnatn -gnato -gnatX -gnatwa -gnatVa ada2012bug2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56118
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
CC||alalaw01 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68165
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68173
Richard Biener changed:
What|Removed |Added
Keywords||ra
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68172
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68173
--- Comment #5 from Richard Biener ---
I wonder what difference
Index: gcc/gimplify.c
===
--- gcc/gimplify.c (revision 229574)
+++ gcc/gimplify.c (working copy)
@@ -499,7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67056
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|2015-08-04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68057
--- Comment #7 from Richard Biener ---
Honza, can you work on this please? It blocks backporting the devirt
wrong-code fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67056
Richard Biener changed:
What|Removed |Added
CC||bnagaev at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68175
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68176
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Target Mil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68178
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68165
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68157
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68179
Bug ID: 68179
Summary: No warning when specifying a Default_Component_Value
on derived type, resulting in unexpected behavior
Product: gcc
Version: 4.9.2
Status: UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016
--- Comment #10 from Yury Gribov ---
> This happens because in LLVM case ASan changes symbols size
> ('f' in our case) and just breaks ABI for the library.
I've filed an upstream bug about this
https://github.com/google/sanitizers/issues/619
79 matches
Mail list logo
