http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902
--- Comment #27 from Markus Trippelsdorf ---
(In reply to Jeffrey A. Law from comment #26)
> Testing is good. Just trying to build a nice little testcase for the
> regression suite.
Thanks. Another thing I've noticed is that ac3 audio doesn't wo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60931
Bug ID: 60931
Summary: libgo has issues when page size is not 4k
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60931
--- Comment #1 from Andrew Pinski ---
This is going to be true on AARCH64 also where most distros are going to be
using 64k pages (some might use 4k pages if they also support AARCH32). MIPS
has many different page sizes too (4k, 8k, 16k, 32k, an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
Bug ID: 60932
Summary: is not C++ compatible
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60931
--- Comment #2 from Anton Blanchard ---
I agree, but when I tried this I found a few places that expect PageSize to be
a compile time constant so it is not as trivial as I had hoped.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60922
Salvatore Filippone changed:
What|Removed |Added
Summary|[4.10 regression] Memory |[4.9/4.10 regression]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60275
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Wed Apr 23 08:20:12 2014
New Revision: 209672
URL: http://gcc.gnu.org/viewcvs?rev=209672&root=gcc&view=rev
Log:
PR sanitizer/60275
* common.opt (fsanitize-recover, fsanitize-undefi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60891
--- Comment #3 from Richard Biener ---
Author: rguenth
Date: Wed Apr 23 08:23:33 2014
New Revision: 209673
URL: http://gcc.gnu.org/viewcvs?rev=209673&root=gcc&view=rev
Log:
2014-04-23 Richard Biener
PR middle-end/60891
* loop-init.c (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60891
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Wed Apr 23 08:25:56 2014
New Revision: 209674
URL: http://gcc.gnu.org/viewcvs?rev=209674&root=gcc&view=rev
Log:
2014-04-23 Richard Biener
PR middle-end/60891
* loop-init.c (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60895
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Wed Apr 23 08:27:00 2014
New Revision: 209675
URL: http://gcc.gnu.org/viewcvs?rev=209675&root=gcc&view=rev
Log:
2014-04-23 Richard Biener
PR middle-end/60895
* tree-inline.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60895
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Wed Apr 23 08:27:37 2014
New Revision: 209676
URL: http://gcc.gnu.org/viewcvs?rev=209676&root=gcc&view=rev
Log:
2014-04-23 Richard Biener
PR middle-end/60895
* tree-inline.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60891
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60895
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60720
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Wed Apr 23 08:31:48 2014
New Revision: 209677
URL: http://gcc.gnu.org/viewcvs?rev=209677&root=gcc&view=rev
Log:
2014-04-23 Richard Biener
Backport from mainline
2014-04-14
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60720
Richard Biener changed:
What|Removed |Added
Known to work||4.9.1
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60720
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60923
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60930
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60929
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.1
Summary|[4.9 Regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60922
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60275
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60923
--- Comment #2 from Mukul Gupta ---
(In reply to Eric Botcazou from comment #1)
> But this works for everyone else so you'll need to debug yourself...
>
> A few remarks/questions:
> 1. What does this "gcc64" mean in the various paths?
> 2. Wh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
Andrew Pinski changed:
What|Removed |Added
Component|c |c++
Summary| is not C++|ma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022
--- Comment #27 from Mircea Namolaru ---
Hi,
Many thanks.
I've passed over the meta-bug opened by you for Graphite,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859 and seems to me
that many of the problem have been already solved (some by you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102
--- Comment #2 from Sebastian Huber ---
Sorry, but my test run on 2014-04-17 used --disable-multilib, so it didn't
build the multilib in question. So the problem was also present on 2014-04-17.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933
Bug ID: 60933
Summary: Please do not advertise outdated version of gmp, mpfr,
mpc
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60731
Ondrej Bilka changed:
What|Removed |Added
CC||neleai at seznam dot cz
--- Comment #9 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
--- Comment #2 from Sebastian Huber ---
So I cannot use C libraries using atomics with C++ on GCC targets? With
FreeBSD and clang this works fine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60903
--- Comment #2 from Richard Biener ---
LIM is the culprit - it does CFG building but those don't properly update
BB/EDGE_IRREDUCIBLE_LOOP.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902
--- Comment #28 from Markus Trippelsdorf ---
(In reply to Markus Trippelsdorf from comment #27)
> (In reply to Jeffrey A. Law from comment #26)
> > Testing is good. Just trying to build a nice little testcase for the
> > regression suite.
>
> An
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60924
--- Comment #5 from Timur Iskhodzhanov ---
Jakub wrote:
> all other attributes are allowed on both declarations and definitions
Can you please point me at the documentation that says that attributes are
allowed on definitions? The page I referen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
--- Comment #3 from Andrew Pinski ---
(In reply to Sebastian Huber from comment #2)
> So I cannot use C libraries using atomics with C++ on GCC targets? With
> FreeBSD and clang this works fine.
Until the c++ front-end implements _Atomic keyword
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60923
--- Comment #3 from Eric Botcazou ---
> I am not that knowledgeable about how compilers are implemented, so i doubt
> that i will be able to debug it myself.
Knowing compiler internals is not required, you just need to debug the segfault
as for a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
--- Comment #4 from Sebastian Huber ---
It is surely not the fault of GCC developers that C and C++ diverge more and
more, but for embedded systems developers this is quite painful.
It is clear that you cannot use C++ header files from C. So if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902
--- Comment #29 from Markus Trippelsdorf ---
(In reply to Markus Trippelsdorf from comment #28)
> (In reply to Markus Trippelsdorf from comment #27)
> > (In reply to Jeffrey A. Law from comment #26)
> > > Testing is good. Just trying to build a n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59105
Pawel Sikora changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60912
--- Comment #2 from Richard Biener ---
Likely related to PR60911, waiting for that to be resolved.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60911
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60934
Bug ID: 60934
Summary: Strtoll Function Always Appears to Return 0 on Solaris
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60934
--- Comment #1 from Andrew Pinski ---
Please add -Wall -Wextrra to gcc's command line and see what the warnings are.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60934
--- Comment #2 from Andrew Pinski ---
I give you a hint the format for printing long long is %lld and not just %ld.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60935
Bug ID: 60935
Summary: Endless loop when compiling a recursive function
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
Bug ID: 60936
Summary: Binary code bloat with std::string
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60934
--- Comment #3 from william.speak at sophos dot com ---
(In reply to Andrew Pinski from comment #2)
> I give you a hint the format for printing long long is %lld and not just %ld.
Yep. That was from when I was seeing what could trigger the bug. Re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60903
--- Comment #3 from Richard Biener ---
Author: rguenth
Date: Wed Apr 23 11:25:27 2014
New Revision: 209694
URL: http://gcc.gnu.org/viewcvs?rev=209694&root=gcc&view=rev
Log:
2014-04-23 Richard Biener
PR tree-optimization/60903
* tree-s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60903
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Wed Apr 23 11:27:29 2014
New Revision: 209695
URL: http://gcc.gnu.org/viewcvs?rev=209695&root=gcc&view=rev
Log:
2014-04-23 Richard Biener
PR tree-optimization/60903
* tree-s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60937
Bug ID: 60937
Summary: -Os -fprofile-arcs breaks __attribute__((error()))
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60911
--- Comment #3 from Martin Jambor ---
(In reply to Richard Biener from comment #2)
> Late IPA passes need all regular IPA transforms applied and clones
> materialized.
I agree that would make sense but it is not what we do. Just look at
compile(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60911
--- Comment #4 from rguenther at suse dot de ---
On Wed, 23 Apr 2014, jamborm at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60911
>
> --- Comment #3 from Martin Jambor ---
> (In reply to Richard Biener from comment #2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60938
Bug ID: 60938
Summary: AIX: exceptions not caught when calling function via
pointer
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60939
Bug ID: 60939
Summary: AIX: exceptions not caught when calling function via
pointer
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60939
--- Comment #1 from lbl2007 at gmx dot net ---
Created attachment 32661
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32661&action=edit
Test program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
--- Comment #1 from __vic ---
If we use iostream classes (without std::string) the difference isn't so
dramatic:
4.7: 800320
4.8: 838944
4.9: 868664
May be it's connected with locales? Has std::string any dependences on it in
4.9?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60934
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60938
lbl2007 at gmx dot net changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60911
--- Comment #5 from Richard Biener ---
Ah, and tree-ssa-structalias.c does
/* Build the constraints. */
FOR_EACH_DEFINED_FUNCTION (node)
{
varinfo_t vi;
/* Nodes without a body are not interesting. Especially do not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60939
--- Comment #2 from lbl2007 at gmx dot net ---
*** Bug 60938 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60911
--- Comment #6 from Richard Biener ---
Seems like simd_clone_create gets along with this because it does
if (!cgraph_function_with_gimple_body_p (old_node))
return NULL;
cgraph_get_body (old_node);
new_node = cgraph_func
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60911
--- Comment #7 from Richard Biener ---
Anyway, that push/pop_cfun stuff should be pushed to the callbacks, not be
done in do_per_function (). Likewise the ggc_collect ().
Btw, same code in do_per_function_toporder.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60930
Bill Schmidt changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
--- Comment #2 from __vic ---
Non-stripped binary built with 4.9 has many symbols from locale. 4.8 - doesn't.
How std::string uses locales???
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59132
--- Comment #1 from Jan Smets ---
Ping
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
Jan Smets changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60635
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Wed Apr 23 12:45:23 2014
New Revision: 209696
URL: http://gcc.gnu.org/viewcvs?rev=209696&root=gcc&view=rev
Log:
2014-04-23 Richard Biener
PR middle-end/60635
* gimplify.c (g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60740
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Wed Apr 23 12:49:04 2014
New Revision: 209697
URL: http://gcc.gnu.org/viewcvs?rev=209697&root=gcc&view=rev
Log:
2014-04-23 Richard Biener
Backport from mainline
2014-04-02
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60729
--- Comment #6 from Richard Biener ---
Author: rguenth
Date: Wed Apr 23 12:49:04 2014
New Revision: 209697
URL: http://gcc.gnu.org/viewcvs?rev=209697&root=gcc&view=rev
Log:
2014-04-23 Richard Biener
Backport from mainline
2014-04-02
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60635
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60729
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859
Bug 59859 depends on bug 60740, which changed state.
Bug 60740 Summary: [4.8 Regression] ICE in extract_affine w/ -O2
-ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60740
What|Removed |Added
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60740
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
--- Comment #5 from Jonathan Wakely ---
(In reply to Sebastian Huber from comment #4)
> It is clear that you cannot use C++ header files from C. So if you want to
> provide a library intended for C and C++ applications you must use C as the
> bas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
--- Comment #6 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #5)
> #ifdef __cplusplus
> #include
> using namespace std;
> #else
> #include
> #endif
>
> atomic i;
Doh, sorry, that should say atomic_int not atomic
(I changed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56019
--- Comment #6 from Jonathan Wakely ---
(In reply to Jobst.Ziebell from comment #4)
> Presumably this bug also occurs when #defining the other '__need_*' macros.
Which user code should never be doing anyway.
GMP is broken (and already fixed upst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55817
Jonathan Wakely changed:
What|Removed |Added
Version|4.9.0 |4.7.1
Resolution|WORKSFORME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
--- Comment #7 from Jonathan Wakely ---
(In reply to Sebastian Huber from comment #2)
> With FreeBSD and clang this works fine.
Not on my freebsd host:
$ clang++ -std=c++11 a.cc
In file included from a.cc:5:
/usr/include/stdatomic.h:187:17: erro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60940
Bug ID: 60940
Summary: general operations on atomic t ypes do not work with
atomic integral typedefs
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Keywords: r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60911
--- Comment #8 from Richard Biener ---
Created attachment 32662
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32662&action=edit
cleanup patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
--- Comment #8 from Jonathan Wakely ---
(In reply to Sebastian Huber from comment #4)
> I don't think this is the spirit of the atomics provided
> by the recent C/C++ standards.
The atomics are supposed to be roughly source-compatible, in that th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
--- Comment #9 from Sebastian Huber ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Sebastian Huber from comment #4)
> > It is clear that you cannot use C++ header files from C. So if you want to
> > provide a library intended fo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
--- Comment #10 from Jonathan Wakely ---
(In reply to Sebastian Huber from comment #9)
> Who guarantees that this definition is binary compatible in C and C++?
The compiler/stdlib implementors.
The same people who you want to guarantee that if y
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
Sebastian Huber changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60915
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60941
Bug ID: 60941
Summary: gcc 4.8.3/sparc64 miscompiles firefox javascript
interpreter
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60941
--- Comment #1 from Martin Husemann ---
Here is a small test program:
---8<---
#include
#include
int main(int argc, char **argv)
{
unsigned long v[2], *p;
int a, b;
for (int i = 0; i < 2 && i < argc; i++) {
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933
--- Comment #2 from Jonathan Wakely ---
We've had situations in the past where the minimum suggested versions work and
the latest versions prevented GCC from building. The suggested versions are
known to work and have been thoroughly tested, which
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52416
SANTOS.RAMÍREZ changed:
What|Removed |Added
CC||santos.ramirez at siemens dot
com
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933
--- Comment #4 from Vincent Lefèvre ---
Alternatively you should say that:
* these minimal versions should be used with GCC only, and should not be
installed on the system;
* bugs related to them should be reported to some GCC mailing-list, not to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933
--- Comment #5 from Eric Botcazou ---
> Alternatively you should say that:
> * these minimal versions should be used with GCC only, and should not be
> installed on the system;
> * bugs related to them should be reported to some GCC mailing-list,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933
--- Comment #3 from Vincent Lefèvre ---
(In reply to Eric Botcazou from comment #1)
> It's common practice to list the minimally required versions of dependencies
> for software packages, so I'm not sure why we shouldn't do it for GCC.
I don't th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933
--- Comment #6 from Vincent Lefèvre ---
(In reply to Eric Botcazou from comment #5)
> But, again, other software packages don't do that so I'm not sure why GCC
> should do it
I'm not aware of other software packages that provide such old versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60909
--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Apr 23 16:23:36 2014
New Revision: 209709
URL: http://gcc.gnu.org/viewcvs?rev=209709&root=gcc&view=rev
Log:
Backport from mainline
2014-04-21 Uros Bizjak
PR tar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933
--- Comment #7 from Andreas ---
As stated in my report, there is no problem with mentioning the minimal
versions of helper libraries required to compile gcc. The problem is with
actively promoting outdated versions, which can be helped by choosing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902
--- Comment #30 from Jeffrey A. Law ---
Sorry. I expect to check the fix & testcase onto the trunk today. For various
reasons my work time is limited right now. For the 4.9.x releases, final call
will be with jakub, jsm and richi as the releaes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60931
--- Comment #3 from Ian Lance Taylor ---
It would be extremely helpful if you could find a test case that can recreate
this problem with some reliability. There is no obvious dependency on the
system page size in libgo. The PageSize constant is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933
--- Comment #8 from Jonathan Wakely ---
(In reply to Andreas from comment #7)
> Even if you are weary of the latest and greatest version, a position I can
> understand, you should not actively distribute releases that have been
> unmaintained for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60940
--- Comment #1 from Jonathan Wakely ---
Additionally, we fail to meet this requirement:
29.6.2 Templated operations on atomic types [atomics.types.operations.templ]
The implementation shall declare but not define the function templates
identifi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60942
Bug ID: 60942
Summary: ICE on invalid code in unify_one_argument
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60909
--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Apr 23 17:53:56 2014
New Revision: 209715
URL: http://gcc.gnu.org/viewcvs?rev=209715&root=gcc&view=rev
Log:
Backport from mainline
2014-04-21 Uros Bizjak
1 - 100 of 148 matches
Mail list logo
