https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69806
--- Comment #10 from Oleg Endo ---
(In reply to Jakub Jelinek from comment #9)
> Please see PR69671 then, that CSE change is right, so you really need to
> find some solution at the backend side. Look what fwprop* dumps show etc.
I've checked t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881
--- Comment #3 from Bernd Edlinger ---
or
#undef all these __need_XXX before including stddef.h,
after all it is a bit bogus ghat gmp.h does:
#define __need_size_t /* tell gcc stddef.h we only want size_t */
#include /* for size_t */
is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881
--- Comment #4 from Jonathan Wakely ---
The patch seems wrong, your new sections don't add anything to namespace std.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881
--- Comment #5 from Jonathan Wakely ---
(In reply to Bernd Edlinger from comment #3)
> or
>
> #undef all these __need_XXX before including stddef.h,
> after all it is a bit bogus ghat gmp.h does:
>
> #define __need_size_t /* tell gcc stddef.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881
--- Comment #6 from Bernd Edlinger ---
(In reply to Jonathan Wakely from comment #4)
> The patch seems wrong, your new sections don't add anything to namespace std.
yes. I think probably cstddef is free to ignore __need_size_t. right?
Then it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64324
--- Comment #4 from Paul Thomas ---
(In reply to Paul Thomas from comment #3)
> Fixed on trunk. I will wait a few weeks before fixing on 5-branch.
>
> Paul
This has been on hold awaiting a fix for PR69423 on trunk. It looks as if the
wait is ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881
--- Comment #7 from Bernd Edlinger ---
Index: include/c_global/cstddef
===
--- include/c_global/cstddef(revision 233581)
+++ include/c_global/cstddef(working copy)
@@ -41,6 +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881
--- Comment #8 from Bernd Edlinger ---
BTW:
the free-standing cstddef is also buggy:
#define __need_size_t
#define __need_ptrdiff_t
#define __need_NULL
#define __need_offsetof
#include_next
but GCC's stddef.h does not implement __need_offseto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881
--- Comment #9 from Bernd Edlinger ---
right now I am trying to boot-strap this:
Index: c/cstddef
===
--- c/cstddef (revision 233581)
+++ c/cstddef (working copy)
@@ -31,10 +31,
ttached test case emits wrong reduction statements.
Compile:
$ trunk/64/20160220/bin/gfortran -o repro -static -m64 -Ofast -mavx repro.f90
Execution ABORTs
Works fine when compiled w/ -O0
Extract from vectorizer dump:
:
# k_239 = PHI
# c_I_lsm.10_241 = PHI
# c_I_lsm.11_242 = PHI
#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69882
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881
--- Comment #11 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #10)
> Why should libstdc++ try to workaround a bug in gmp.h? Just fix gmp.h...
Yes, and probably it is already fixed with gmp-6.1.0, I did not check.
I am trying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #59 from Dominique d'Humieres ---
> We already warn about mismatches sizes at LTO link time
Confirmed
[Book15] f90/bug% gfc -c -O2 pr69368_a.f90 -flto
[Book15] f90/bug% gfc -O2 pr69368_a.o pr69368_b.f90 -flto
pr69368_a.f90:3:0: warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52531
--- Comment #12 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sat Feb 20 14:10:55 2016
New Revision: 233588
URL: https://gcc.gnu.org/viewcvs?rev=233588&root=gcc&view=rev
Log:
2016-02-20 Dominique d'Humieres
PR fortran/5736
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57365
--- Comment #5 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sat Feb 20 14:10:55 2016
New Revision: 233588
URL: https://gcc.gnu.org/viewcvs?rev=233588&root=gcc&view=rev
Log:
2016-02-20 Dominique d'Humieres
PR fortran/57365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580
vries at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69883
Bug ID: 69883
Summary: gcc-6.0 unable to build gcc-4.9 with ada
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69883
Arnaud Charlet changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69883
--- Comment #2 from Bernd Edlinger ---
(In reply to Arnaud Charlet from comment #1)
> You must use an older (or equal) version of GNAT to build GNAT, using a more
> recent version won't work in general, as shown by this PR, and isn't
> supported.
> I could understand that I can not build something form 1992 with todays
> tools, but what I do not understand conceptionally, why the host compiler
> seems to link with the target compiler's runtime, would it work as a
> cross build then?
No, for a cross build you need an identical native compil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69883
--- Comment #3 from charlet at adacore dot com ---
> I could understand that I can not build something form 1992 with todays
> tools, but what I do not understand conceptionally, why the host compiler
> seems to link with the target compiler's ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69883
--- Comment #4 from Bernd Edlinger ---
(In reply to char...@adacore.com from comment #3)
> > I could understand that I can not build something form 1992 with todays
> > tools, but what I do not understand conceptionally, why the host compiler
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126
--- Comment #26 from David Malcolm ---
(In reply to David Malcolm from comment #25)
[...]
> I have a patch that seems to work for this test case; am testing it more
> thoroughly now.
Candidate patch posted here:
https://gcc.gnu.org/ml/gcc-patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881
--- Comment #12 from Jonathan Wakely ---
(In reply to Bernd Edlinger from comment #9)
> right now I am trying to boot-strap this:
>
> Index: c/cstddef
> ===
> --- c/cstddef (revisio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69884
Bug ID: 69884
Summary: [6 Regression] warning: ignoring attributes on
template argument
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69884
--- Comment #1 from Markus Trippelsdorf ---
Created attachment 37744
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37744&action=edit
unreduced testcase
markus@x4 build % g++ -O2 -c sparse_product.ii 2>&1 | grep "ignoring attributes
on tem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69884
--- Comment #2 from Markus Trippelsdorf ---
At least there should be way to silence this warning.
There is a patch already:
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg02256.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69423
--- Comment #11 from Paul Thomas ---
Author: pault
Date: Sat Feb 20 18:26:59 2016
New Revision: 233589
URL: https://gcc.gnu.org/viewcvs?rev=233589&root=gcc&view=rev
Log:
2016-02-20 Paul Thomas
PR fortran/69423
* trans-decl.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881
--- Comment #13 from Bernd Edlinger ---
(In reply to Jonathan Wakely from comment #12)
> (In reply to Bernd Edlinger from comment #9)
> > right now I am trying to boot-strap this:
> >
> > Index: c/cstddef
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61156
--- Comment #6 from Jerry DeLisle ---
Proposed patch:
diff --git a/gcc/fortran/scanner.c b/gcc/fortran/scanner.c
index c1d79457..c4e7974e 100644
--- a/gcc/fortran/scanner.c
+++ b/gcc/fortran/scanner.c
@@ -336,7 +336,7 @@ add_path_to_list (gfc_d
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
seen building a m68k-linux-gnu cross compiler, trunk 20160220:
$ cat libgcc2.i
typedef int DItype __attribute__
--with-sysroot=/usr/aarch64-unknown-linux-gnu --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-233588-checking-yes-rtl-df-nographite-aarch64
Thread model: posix
gcc version 6.0.0 20160220 (experimental) (GCC)
$ aarch64-unknown-linux-gnu-gcc -Os --param=gcse-unrestricted-cost=0 tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69884
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
--- Comment #28 from Mark Wielaard ---
(In reply to Panu Matilainen from comment #26)
> On main files warning on unused junk is certainly useful but static const is
> commonly and deliberately used in headers (eg for arrays such as in comment
> #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
--- Comment #29 from Mark Wielaard ---
(In reply to Manuel López-Ibáñez from comment #27)
> (In reply to Mark Wielaard from comment #21)
> > Although in C a static const is not really like a #define I suspect that
> > there are cases where they a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
--- Comment #30 from Mark Wielaard ---
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01433.html
/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160220 (experimental) [trunk revision 233587] (GCC)
$ gcc-trunk -O1 abc.c
abc.c: In function 'main':
abc.c:6:1: internal compiler error: in mark_jump_label_1, at j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
Mikhail Maltsev changed:
What|Removed |Added
CC||miyuki at gcc dot gnu.org
--- Comment
39 matches
Mail list logo
