https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65675
Bug ID: 65675
Summary: make bootstrap fails when configured with
--disable-hosted-libstdcxx
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: blocker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65662
--- Comment #8 from vekumar at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to vekumar from comment #6)
> > For 42 bit VA, I have to change the SANITIZER_MMAP_RANGE_SIZE to 1 <<42.
>
> Sure.
>
> > Also compiler h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #25 from Jan Hubicka ---
Crafty perfomrance is back (with a combination of better heuristics and
increase of inlining limits), eon is not, at least not in all configurations.
We have separate eon PR, so I am closing this one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #22 from drikosev at otenet dot gr ---
Created attachment 35234
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35234&action=edit
cleanup if a declaration type spec is erroneous
Let's see if the function names are properly printe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65674
Bug ID: 65674
Summary: stack smashing protector must be controllable
per-function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65647
--- Comment #7 from Jakub Jelinek ---
So fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65662
--- Comment #7 from Jakub Jelinek ---
(In reply to vekumar from comment #6)
> For 42 bit VA, I have to change the SANITIZER_MMAP_RANGE_SIZE to 1 <<42.
Sure.
> Also compiler has to add the shadow offset instead of Oring it.
You don't, see my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63579
Marc Glisse changed:
What|Removed |Added
Attachment #33750|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #21 from drikosev at otenet dot gr ---
Created attachment 35232
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35232&action=edit
cleanup if a declaration type spec is erroneous
Finally, I've sent for review to the recommended re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65647
--- Comment #6 from Yvan Roux ---
Author: yroux
Date: Sun Apr 5 19:06:43 2015
New Revision: 221873
URL: https://gcc.gnu.org/viewcvs?rev=221873&root=gcc&view=rev
Log:
gcc/
2015-04-05 Yvan Roux
Backport from trunk r221867
2015-04-04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65535
Martin Sebor changed:
What|Removed |Added
Severity|normal |minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65484
Martin Sebor changed:
What|Removed |Added
Severity|minor |normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65484
Martin Sebor changed:
What|Removed |Added
Severity|normal |minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65535
Martin Sebor changed:
What|Removed |Added
Target|powerpc64-freebsd |*-*-freebsd
--- Comment #4 from Martin Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65665
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65665
--- Comment #9 from Martin Liška ---
Author: marxin
Date: Sun Apr 5 17:17:29 2015
New Revision: 221872
URL: https://gcc.gnu.org/viewcvs?rev=221872&root=gcc&view=rev
Log:
Fix PR ipa/65665
PR ipa/65665
* ipa-icf.c (sem_function::equals_w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #20 from Dominique d'Humieres ---
> Also, I think that the additional test could be: "( m != MATCH_OK )"
I don't think so: the block in the patch will be reached for (m == MATCH_NO)
and I think this leads to the regressions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #19 from drikosev at otenet dot gr ---
Ok, I'll send a patch to the recommended addresses as soon as I read the GNU
coding standards.
Yet, my impression is that perhaps the patch should be a bit more complex; in
example, I think tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65662
vekumar at gcc dot gnu.org changed:
What|Removed |Added
CC||vekumar at gcc dot gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #18 from Dominique d'Humieres ---
With an additional filtering on (m == MATCH_ERROR), i.e. with the following
patch, the ICEs are fixed without regression
--- ../_clean/gcc/fortran/decl.c2015-03-25 14:07:04.0 +0100
+++ gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #17 from Dominique d'Humieres ---
I have forgotten to give a sample of the failing tests with the patch in
comment 15:
FAIL: gfortran.dg/coarray/alloc_comp_3.f90 -fcoarray=single -O2 -latomic
(test for excess errors)
FAIL: gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #16 from Dominique d'Humieres ---
> As it seems the problem with the program bug.f90 is that the generic
> attribute is set in a symbol as the parser tries to match a declaration
> type specification; but finally, the statement isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61347
--- Comment #4 from Marc Glisse ---
Created attachment 35231
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35231&action=edit
Overload of __distance
Here is one way to do it (I will probably protect the new code with
defined(__OPTIMIZE__)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #15 from drikosev at otenet dot gr ---
Created attachment 35230
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35230&action=edit
altered patch for the regressions reported in comment 11
Hi,
As it seems the problem with the prog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65647
--- Comment #5 from Yvan Roux ---
Created attachment 35229
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35229&action=edit
testcase that fails also on 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65647
Yvan Roux changed:
What|Removed |Added
CC||yroux at gcc dot gnu.org
--- Comment #4 from
26 matches
Mail list logo
