http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203
--- Comment #5 from Lubos Lunak ---
Gcc patch is in, r200941.
Keeping open for libstdc++ to use the attribute for its relevant classes. I can
try to submit a patch when I find the time, but I doubt I'll get past the most
obvious classes, so anyon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711
--- Comment #6 from Tobias Burnus ---
Patch for PR40276 and this PR:
http://gcc.gnu.org/ml/fortran/2013-06/msg00132.html (approved).
It fails for the test case http://gcc.gnu.org/ml/fortran/2013-07/msg00017.html
(-> PR39290 and PR20896). In that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40276
--- Comment #3 from Tobias Burnus ---
Patch for PR57711 and this PR:
http://gcc.gnu.org/ml/fortran/2013-06/msg00132.html (approved).
It fails for the test case http://gcc.gnu.org/ml/fortran/2013-07/msg00017.html
(-> PR39290 and PR20896). In that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #6 from Vittorio Zecca ---
The following is a shorter version of Marc's test case:
__get_cpuid_max (unsigned int __ext, unsigned int *__sig) {
unsigned __edx;
__cpuid (0, 0, 0, 0, __edx);
}
int __get_cpuid (unsigned int __level, u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39290
--- Comment #11 from Tobias Burnus ---
See also PR 20896 - and the test case at
http://gcc.gnu.org/ml/fortran/2013-07/msg00017.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #20 from Sebastian Pop ---
-floop-nest-optimize does not have a cost model and so it blocks all loop
nests.
These two stmts are blocked:
A=0.1D0
B=0.1D0
This other stmt is not blocked:
C(I,J)=C(I,J)+A(I,K)*B(K,J)
The only thing we
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #19 from Sebastian Pop ---
Default: tile_size = 32
gfortran -ffast-math -O3 -floop-nest-optimize t.f90 -v
./a.out
176.42500110.2399826
and then with a trivial patch that replaces that default constant 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57717
--- Comment #6 from Khem Raj ---
here is another case which fails before suggested patch and also after the
patch
void foo()
{
double a[2];
double b = 3.1L / 2;
}
Here is result below after applying the patch in comment #3
$ ./gcc/cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #5 from Vittorio Zecca ---
Trying your vastly reduced test case, 152 lines vs 3057 of my original
test case, I am getting
an ICE in convert_move, at expr.c:452.
The following is my backtrace:
: In function ‘__get_cpuid_max’:
:1:1: inte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57885
--- Comment #4 from Jim Hand ---
I compiled 4.9.0-20130714 today and ran the same tests. Here are the results
for the lookup loops with the times for each compiler:
4.6.3: 11536 microseconds
4.7.3: 12150 microseconds (5.3% slower than 4.6.3)
4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56166
--- Comment #9 from Tolga ---
It was a bug in my code that called clear from one thread while other inserts
something.
Yet, it throws.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47425
Tobias Burnus changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #2 from Tob
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57902
Bug ID: 57902
Summary: Bugbox in Ada 95 mode, at ada/gcc-interface/decl.c:342
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56166
--- Comment #8 from Tolga ---
Correction, removing the copy, therefore reference counting effect, feels like
has decreased the error but I found out std::string::clear() still throws
std::length_error, although I use no reference.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56166
Tolga changed:
What|Removed |Added
CC||fasdfasdas at gmail dot com
--- Comment #7 from T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52669
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57901
Bug ID: 57901
Summary: [C++11][constexpr] Cannot call-by-value such that
class has non-trivial (constexpr) move constructor
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57900
--- Comment #3 from Jonathan Wakely ---
See the long thread starting at http://gcc.gnu.org/ml/gcc/2013-07/msg00075.html
If it's easy to solve I'm sure a patch would be welcomed :)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57900
--- Comment #2 from Andreas Schwab ---
It's the target compiler that matters, so this check must be performed in the
target libraries.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57900
Andrew Pinski changed:
What|Removed |Added
Severity|trivial |enhancement
--- Comment #1 from Andrew Pi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57900
Ben Woodard changed:
What|Removed |Added
Severity|minor |trivial
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57900
Bug ID: 57900
Summary: /usr/include/gnu/stubs.h:7:27: fatal error:
gnu/stubs-32.h: No such file or directory
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Seve
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57885
--- Comment #3 from Jim Hand ---
As a simplification, I tried compiling the following code with gcc-4.6.3 into
assembly with gcc-4.6.3 and 4.8.1:
#include
bool contains(std::unordered_map a) {
return a.find(5) != a.end();
}
gcc-4.6.3 genera
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #4 from Marc Glisse ---
Created attachment 30506
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30506&action=edit
Slightly reduced testcase
The bug disappears if we remove some unused typedefs, or the preprocessor line
indication
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44080
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
Mikael Pettersson changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57899
--- Comment #2 from Jonathan Wakely ---
Reduced slightly:
#include
#include
using namespace std;
using namespace std::placeholders;
int main()
{
pair table = {"0123456789012345", 0};
auto get_first = mem_fn(&pair::first);
auto it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57899
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57895
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57898
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57895
Tobias Burnus changed:
What|Removed |Added
Keywords||diagnostic,
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
Mikael Pettersson changed:
What|Removed |Added
CC||mikpe at it dot uu.se
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49138
--- Comment #6 from Tobias Burnus ---
See also:
- http://fedoraproject.org/wiki/PackagingDrafts/FortranLibraries (from 2008)
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714730
+ http://lists.debian.org/debian-science/2013/07/msg00012.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57899
Bug ID: 57899
Summary: bind/function with data member: infinite recursion
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57898
Bug ID: 57898
Summary: std::bind incompatible with ref-qualified ptmf
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57894
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57894
Tobias Burnus changed:
What|Removed |Added
Keywords||accepts-invalid,
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57897
--- Comment #1 from Dongsheng Song ---
$ ~/cross/x86_64-windows-gcc49/bin/x86_64-w64-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=/home/cauchy/cross/x86_64-windows-gcc49/bin/x86_64-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/home/cauchy/cross/x86_64-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57897
Bug ID: 57897
Summary: pragma
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc d
40 matches
Mail list logo