https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77496
--- Comment #4 from Bernd Edlinger ---
(In reply to Bernd Edlinger from comment #3)
> The "correct" test case emits two nearly identical -Wpedantic warnings:
>
... which is probably OK, given the second one if it is emitted,
points to the insta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77496
--- Comment #3 from Bernd Edlinger ---
The "correct" test case emits two nearly identical -Wpedantic warnings:
One when the template is parsed, and one when the template is instantiated.
The second one is unnecessary, IMHO.
template
class z :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77496
--- Comment #2 from Bernd Edlinger ---
possible fix:
--- a/gcc-7-20160904/gcc/cp/class.c 2016-08-26 17:10:57.0 +0200
+++ b/gcc-7-20160904/gcc/cp/class.c 2016-09-06 11:55:27.252138088 +0200
@@ -8262,6 +8262,11 @@ instantiate_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77496
--- Comment #1 from Bernd Edlinger ---
But it works if I write:
int f(bool z) { return zz(0) ? : 0; }
++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
this invalid C++ template creates an ICE:
cat test.cc
template
class z : x
{
public:
bool zz (int) { return false; }
int f(bool z) { return zz ? : 0; }
};
class t
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
see: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00202.html
The problem is that ~ on bool maps [0:1] to [-1:-2]
and thus the result is no longer boolean. But probably the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77434
--- Comment #11 from Bernd Edlinger ---
As I said, I think "<<" on signed integers is generally bogus in a
truth value context.
So I tried an experiment for such a warning:
Index: c-common.c
=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77434
--- Comment #10 from Bernd Edlinger ---
(In reply to Manuel López-Ibáñez from comment #9)
> It seems to me that they are two different warnings that could be triggered
> on similar code. The one warned by the patch would also warn about:
>
> if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77434
--- Comment #7 from Bernd Edlinger ---
(In reply to jos...@codesourcery.com from comment #6)
> On Thu, 1 Sep 2016, bernd.edlinger at hotmail dot de wrote:
>
> > + warning_at (location, 0,
> > + &q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77434
--- Comment #5 from Bernd Edlinger ---
This is an idea for a warning that does not focus on parentheses:
Here we had: a ? c1 : c2;
but in a context where a boolean is requested.
It is always suspicious, when c1, and c2 are integer constants
whic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77434
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330
--- Comment #12 from Bernd Edlinger ---
glibc's malloc returns 128-bit aligned on x86-64-linux-gnu.
but what does it return on windows?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330
--- Comment #11 from Bernd Edlinger ---
(In reply to jos...@codesourcery.com from comment #10)
> On Tue, 23 Aug 2016, bernd.edlinger at hotmail dot de wrote:
>
> > Yes, but isn't that an ABI decision?
>
> It's the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330
--- Comment #9 from Bernd Edlinger ---
(In reply to jos...@codesourcery.com from comment #8)
> On Tue, 23 Aug 2016, bernd.edlinger at hotmail dot de wrote:
>
> > gcc assumes that malloc, calloc, realloc, strdup, strndup
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72856
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #8 from Bernd Edlinger ---
analyzing the different thumb1/2 reload dumps,
I see t2 often uses code like that to access spill slots:
(insn 11576 8090 9941 5 (set (reg:SI 3 r3 [11890])
(plus:SI (reg/f:SI 13 sp)
(con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #7 from Bernd Edlinger ---
even more surprisingly is that:
While thumb2 code (-march=armv6t2 -mthumb) has about the same stack size
as arm code (-marm), thumb1 code has only 1588 bytes stack, and it does
not change with -fno-schedule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
Bernd Edlinger changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #5 from Bernd Edlinger ---
Now I try to clear the out register when the shift < 32
Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c(revision 239624)
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #4 from Bernd Edlinger ---
hmm, when I compare aarch64 vs. arm sha512.c.260r.reload
with -O3 -fno-schedule-insns
I see a big difference:
aarch64 has only few spill regs
subreg regs:
Slot 0 regnos (width = 8): 856
Slot 1 reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #48 from Bernd Edlinger ---
somethin like that fixes it for me:
Index: pr66415-1.c
===
--- pr66415-1.c (revision 239624)
+++ pr66415-1.c (working copy)
@@ -1,6 +1,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #47 from Bernd Edlinger ---
COLUMNS=82 make check-gcc-c RUNTESTFLAGS="cpp.exp=pr66415-1.c"
...
Running /home/ed/gnu/gcc-trunk/gcc/testsuite/gcc.dg/cpp/cpp.exp ...
=== gcc Summary ===
# of expected passes3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71973
--- Comment #3 from Bernd Edlinger ---
Created attachment 39472
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39472&action=edit
possible patch
Oh, yeah!
Boot-strap OK.
The eh-code is OK.
BUT: the warning triggers a few hundred times, w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72873
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72833
--- Comment #12 from Bernd Edlinger ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #10)
> True: the Solaris fix missed this, probably because the issue never came
> up. The Mac OS X 10.8+ has the annotation, so it's probably
> bes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72833
Bernd Edlinger changed:
What|Removed |Added
Attachment #39079|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72833
--- Comment #9 from Bernd Edlinger ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> > --- Comment #6 from Bernd Edlinger ---
> [...]
> > Completely untested patch.
> >
> > Based on the gcc-4.9 solaris patch:
> > just s/solaris/d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72833
Bernd Edlinger changed:
What|Removed |Added
Attachment #39078|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72833
--- Comment #6 from Bernd Edlinger ---
Created attachment 39078
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39078&action=edit
untested patch
Completely untested patch.
Based on the gcc-4.9 solaris patch:
just s/solaris/darwin/
and s/__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71083
Bernd Edlinger changed:
What|Removed |Added
Attachment #39068|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72833
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71083
--- Comment #7 from Bernd Edlinger ---
Created attachment 39068
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39068&action=edit
proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71083
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71779
--- Comment #19 from Bernd Edlinger ---
Created attachment 39036
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39036&action=edit
combined patch
Hi,
I've updated the patch again based on Segher's comments.
So that's what I'd like to post
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71779
--- Comment #17 from Bernd Edlinger ---
And here an alternative patch for the other paradoxical subreg bug:
Index: cse.c
===
--- cse.c (revision 238891)
+++ cse.c (worki
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71779
--- Comment #16 from Bernd Edlinger ---
Alternative patch, that looks like it fixes this issue (but not the other bug).
Note: it generates one instruction more than the first patch, thus
paradoxical subregs trigger at least one other bug, and ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71779
--- Comment #15 from Bernd Edlinger ---
patch posted here:
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01742.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71779
--- Comment #10 from Bernd Edlinger ---
(In reply to James Greenhalgh from comment #2)
>
> So I have two questions.
>
> First, where did the DImode paradoxical subreg come from in the first place,
> and why wasn't it a zero-extend?
>
> Second,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71779
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71973
--- Comment #1 from Bernd Edlinger ---
the bug goes away, if the fork signature is correct.
extern "C"
int fork () __attribute__((nothrow));
void bar () throw()
{
fork ();
}
does the right thing.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
I noticed that C++ does not emit a warning when
the header defines a built-in function with a
different/wrong signature.
For instance int fork(void) is a built-in EXT-LIB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876
--- Comment #11 from Bernd Edlinger ---
(In reply to Jeffrey A. Law from comment #10)
> No opinion on the "x" prefix. I think that was already in place when that
> code was updated to support qsetjmp and savectx in the early 90s. I've
> never s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876
--- Comment #9 from Bernd Edlinger ---
(In reply to Jeffrey A. Law from comment #8)
> Light searching doesn't find anything useful for setjmp_syscall.
>
> savectx however still shows up in a variety of solaris searches. In fact,
> you can find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876
--- Comment #7 from Bernd Edlinger ---
Created attachment 38915
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38915&action=edit
possible patch
This is an attempt of a fix.
Not really perfect, but should be at least safe.
Only ECF_RETURN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876
--- Comment #6 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #5)
> Perhaps ECF_MAY_BE_ALLOCA too? But ECF_NORETURN and ECF_LEAF are not
> conservative, sure.
Yes. That's right.
alloca can not return null.
See tree_expr_nonzero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876
--- Comment #4 from Bernd Edlinger ---
And, what is "qsetjmp" ?
Also "setjmp_syscall", "savectx" are also completely new to me.
And why is the prefix "__x" discarded?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876
--- Comment #2 from Bernd Edlinger ---
test case for the ECF_LEAF:
test.c:
int setjmp(void);
static int x;
void foo(int z)
{
x = z;
}
int bar(void)
{
int z = x;
setjmp();
z += x;
return z;
}
gcc -O3 -S -ffreestanding test.c
bar:
.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876
--- Comment #1 from Bernd Edlinger ---
I'm unsure, if ECF_LEAF is also unsafe:
/* The function does not lead to calls within current function unit. */
#define ECF_LEAF (1 << 10)
I couldn't guarantee for that in a freestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104
--- Comment #18 from Bernd Edlinger ---
(In reply to rguent...@suse.de from comment #17)
> Can you open a separate bug please?
sure: pr71876
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
Even with -ffreestanding we handle some functions conservatively.
See special_function_p.
However, the function longjmp and siglongjmp are not handled conservatively
as the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104
--- Comment #16 from Bernd Edlinger ---
(In reply to rguent...@suse.de from comment #15)
> On Thu, 14 Jul 2016, bernd.edlinger at hotmail dot de wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104
> >
> > --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104
--- Comment #14 from Bernd Edlinger ---
One question though...
This depends on a special knowledge about "vfork",
but it seems that gcc does not honor -ffreestanding
correctly in this case, because:
gcc -ffreestanding pr71104-1.c
should not ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71816
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71736
--- Comment #4 from Bernd Edlinger ---
gcc -c min.c
min.c: In function 'signal_handler':
min.c:28:36: warning: implicit declaration of function 'bb_error_msg_and_die'
[-Wimplicit-function-declaration]
).__i))) & 0x7f) + 1) >> 1) > 0) ) bb_error_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71736
--- Comment #3 from Bernd Edlinger ---
Created attachment 38819
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38819&action=edit
delta-reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71736
--- Comment #2 from Bernd Edlinger ---
Created attachment 38818
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38818&action=edit
preprocessed source code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71736
--- Comment #1 from Bernd Edlinger ---
full command line was:
gcc -Wp,-MD,mailutils/.mail.o.d -std=gnu99 -Iinclude -Ilibbb -include
include/autoconf.h -D_GNU_SOURCE -DNDEBUG -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D"B
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
Hi,
when building the latest stable busybox version 2.24.2
there is an ICE in verify_ssa:
make defconfig
make
CC mailutils/mail.o
mailutils/mail.c: In function 'launch_h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67037
--- Comment #10 from Bernd Edlinger ---
(In reply to Richard Earnshaw from comment #9)
> Any plans to backport to 4.9, or should this be closed?
I won't have time/resources for the necessary regression testing.
However the patch is quite simple,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71481
--- Comment #8 from Bernd Edlinger ---
(In reply to David Malcolm from comment #6)
> I wonder if it would be better to instead hardcode LANG=C in the Makefile.am
> hooks that run the selftests? The DejaGnu-based testsuite does that.
Well, hopef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71481
--- Comment #7 from Bernd Edlinger ---
(In reply to David Malcolm from comment #3)
> Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00755.html
BTW: this patch seems not to remove the tempfile again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71481
--- Comment #5 from Bernd Edlinger ---
this seems to fix it:
Index: input.c
===
--- input.c (Revision 237323)
+++ input.c (Arbeitskopie)
@@ -1210,7 +1210,7 @@
static void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71481
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68843
Bernd Edlinger changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728
--- Comment #26 from Bernd Edlinger ---
with unpatched trunk and mpfr-3.1.4 and mpc-1.0.3 in-tree
I've got this in mpc/src/libmpc.la:
dependency_libs=' -lmpfr /home/ed/gnu/gcc-build1/./gmp/.libs/libgmp.la -lm'
and check-mpc fails to build this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728
--- Comment #24 from Bernd Edlinger ---
Created attachment 38101
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38101&action=edit
possible patch
Hi,
this is a patch that fixes the check-mpc issue and
fixes gmp-6.1.0 in-tree
The reason fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728
--- Comment #23 from Bernd Edlinger ---
Hi,
I tried this combination in-tree:
gmp -> gmp-6.1.0
mpfr -> mpfr-3.1.3
mpc -> mpc-1.0.3
isl -> isl-1.15
While I can now reproduce the original problem,
I noticed another anomaly:
make check-mpc fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #26 from Bernd Edlinger ---
I just fail to understand why we cannot just clobber the whole
object once in the in-charge constructor,
then if sanitizing vptrs initialize every vptr once to zero.
and skip all the clobber and vptr initia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728
--- Comment #16 from Bernd Edlinger ---
you should use whatever gmp,mpfr,mpc version you like.
with or without assembly should not make any difference.
That should work, but dont expect it to work in-tree.
Instead use the --with-gmp --with-mpfr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #19 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #18)
> (In reply to Bernd Edlinger from comment #17)
> >
> > Do you see a way, how to conditionalize the clobber on the in_charge?
>
> Very easily, by wrapping the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #17 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #16)
> Created attachment 37965 [details]
> gcc6-pr70147-2.patch
>
this patch looks good to me.
Thanks.
> As the compromise I meant this instead (incremental patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #15 from Bernd Edlinger ---
Yep, maybe this would be a compromise:
Index: cp-ubsan.c
===
--- cp-ubsan.c (revision 234184)
+++ cp-ubsan.c (working copy)
@@ -285,6 +285,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #14 from Bernd Edlinger ---
Hi Jakub,
I played a bit with your proposed patch.
consider this test case:
cat test2.cc
struct A { ~A() {} A () {} A (int x) : a (x) {} virtual void f () {} virtual
int i () { return 0; } int a; };
stru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #12 from Bernd Edlinger ---
I think it is normal, that A's vptr is initialized first to
an A which means that f points to A::f and i points to A::i.
these overloads are usable while A's constructor runs.
The vptr is later changed to t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728
--- Comment #12 from Bernd Edlinger ---
It is on purpose that the in-tree gmp is configured to use no assembly,
but the in-tree configuration does not really work with gmp-6.1.0,
and apparently disables the assembly only half-way. It is not poss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #10 from Bernd Edlinger ---
Created attachment 37959
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37959&action=edit
proposed patch
I don't think that it is necessary to initialize virtual base class vptrs
here, because it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #7 from Bernd Edlinger ---
But how about that?
diff -up gcc/cp/cp-ubsan.c.jj gcc/cp/cp-ubsan.c
--- gcc/cp/cp-ubsan.c.jj2016-03-04 23:10:49.0 +0100
+++ gcc/cp/cp-ubsan.c 2016-03-14 12:09:38.730344495 +0100
@@ -283,7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728
--- Comment #9 from Bernd Edlinger ---
(In reply to Andrew Roberts from comment #8)
> The initial bug report was for cross compiling. Bug 70211 is for native
> builds on ARM. Given the huge growth in ARM development boards, this needs
> at least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70035
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959
--- Comment #3 from Bernd Edlinger ---
Hi Markus,
it should work now.
Please update gcc-5 to r233720 and try again.
Bernd.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881
Bernd Edlinger changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881
--- Comment #22 from Bernd Edlinger ---
yes, I would really have liked the warning, but...
/../gcc-trunk/gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc-trunk/gcc/../libbacktrace -I/home/ed/gnu/gcc-build/./isl/include
-I/home/ed/gnu/gcc-tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881
--- Comment #21 from Bernd Edlinger ---
(In reply to Jonathan Wakely from comment #20)
> (In reply to Bernd Edlinger from comment #19)
> > But I am sure that #define __need_offsetof can simply not work.
>
> So don't define that. It's undefined b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881
--- Comment #19 from Bernd Edlinger ---
(In reply to Jonathan Wakely from comment #18)
> > Yes, I do have such targets.
> > We use eCos at Softing as real time O/S a lot.
>
> Great, that's good to know.
>
> > I think I will build an ecos cross c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881
--- Comment #17 from Bernd Edlinger ---
Created attachment 37749
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37749&action=edit
prerequisite patch to make c_std headers compile
not perfect, but probably an improvement...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881
--- Comment #16 from Bernd Edlinger ---
> But it does not look like the c_std headers are currently working.
> I've got symlinks to non-existing c_std header files:
>
> ccomplex
> cfenv
> cinttypes
> cstdalign
> cstdbool
> cstdint
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881
--- Comment #15 from Bernd Edlinger ---
(In reply to Jonathan Wakely from comment #12)
> > Index: c_std/cstddef
> > ===
> > --- c_std/cstddef (revision 233581)
> > +++ c_std/cstdde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881
--- Comment #14 from Bernd Edlinger ---
OK, I built the ecos cross compiler now.
It works. But eCos headers don't work well with C99 because of
duplicate symbols with inline functions, so I have to use -std=c89,
but that started with gcc-5, so t
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=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=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.
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
Hi,
I am trying to boot-strap gcc-4.9 with gcc-6 as of today.
gcc-6 is configured as:
../gcc-trunk/configure --prefix=/home/ed/gnu/install
--enable-languages=all,ada,go,obj-c
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=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,
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 #7 from Bernd Edlinger ---
Index: include/c_global/cstddef
===
--- include/c_global/cstddef(revision 233581)
+++ include/c_global/cstddef(working copy)
@@ -41,6 +
401 - 500 of 958 matches
Mail list logo
