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=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 #2 from Bernd Edlinger ---
Something like that might be needed?
Index: c_global/cstddef
===
--- c_global/cstddef(Revision 233574)
+++ c_global/cstddef(Arbeitskop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881
--- Comment #1 from Bernd Edlinger ---
note: back-porting r233572 will still be necessary to build 4.9 with gcc-6
but the build fails earlier than that.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
Created attachment 37742
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37742&action=edit
preprocessed source code
g++ -c -g -DIN_GCC-fno-exceptio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69865
Bernd Edlinger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69865
--- Comment #8 from Bernd Edlinger ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Bernd Edlinger from comment #1)
> > weird:
> > If I add -std=c++14 (or any other c++ version, including -ansi)
> > to the command line, it works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69865
--- Comment #6 from Bernd Edlinger ---
also the -fno-extended-identifiers option is broken:
cat test1.cc
// \u00e4 = ä, \u00f6 = ö, \u00fc = ü, \u00df = ß
int test\u00e4\u00f6\u00fc\u00df ()
{
return 0;
}
gcc -fno-extended-identifiers -c test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69865
--- Comment #5 from Bernd Edlinger ---
Created attachment 37736
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37736&action=edit
possible patch
this tries to be compatible to previous gcc versions (option a).
always define __GNUC_GNU_INLI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69865
--- Comment #4 from Bernd Edlinger ---
when working on a patch I noticed that there is something more...
that is if the preprocessor macro __GNUC_GNU_INLINE__ or __GNUC_STDC_INLINE__
is defined on C++. Actually that is irrellevant to C++, but i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69865
--- Comment #2 from Bernd Edlinger ---
in gcc/c-family/c-opts.c:
following code in line 805:
/* Set C++ standard to C++14 if not specified on the command line. */
if (c_dialect_cxx () && cxx_dialect == cxx_unset)
set_std_cxx14 (/*ISO*/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69865
--- Comment #1 from Bernd Edlinger ---
weird:
If I add -std=c++14 (or any other c++ version, including -ansi)
to the command line, it works.
: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
Hi,
I know, nobody likes them, but...
cat test.cc
int
main ()
??<
return 0;
??>
gcc -trigraphs test.cc
test.cc:3:1: warning: trigraph ??< ignored, use -trigraphs to enable
[-W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52085
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69669
--- Comment #4 from Bernd Edlinger ---
it is pretty much completely broken also long before gcc-5:
typedef enum __attribute__((mode(QI))) e
{
e1 = 1,
e2 = 2
} ee;
ee x;
int y;
int test()
{
y=sizeof(x);
return x == e1;
}
in "C" sizeof(
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
Created attachment 37576
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37576&action=edit
reduced test case
Hi,
the attached program gives ICE with gcc-6 trunk:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53440
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69581
--- Comment #10 from Bernd Edlinger ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Bernd Edlinger from comment #7)
> > Thanks. Now about reversing the comments at the bottom of math.h ?
>
> I don't understand the question. I a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69581
--- Comment #7 from Bernd Edlinger ---
Thanks. Now about reversing the comments at the bottom of math.h ?
Index: libstdc++-v3/include/c_compatibility/math.h
===
--- libstdc++-v3/in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69581
--- Comment #4 from Bernd Edlinger ---
this fixes it for me:
Index: libstdc++-v3/include/c_compatibility/math.h
===
--- libstdc++-v3/include/c_compatibility/math.h (revision 233023)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69581
--- Comment #3 from Bernd Edlinger ---
(In reply to Andrew Pinski from comment #1)
> I am surprised you are not using a sysroot.
Hmm, I kind of stole the include/lib files from the target,
and install them to the prefix tree at the right place.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69581
--- Comment #2 from Bernd Edlinger ---
Created attachment 37534
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37534&action=edit
preprocessed source code
++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
I'm using glibc 2.15 at $prefix/$target/include
this works:
../gcc-trunk/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf-linux64
--target=arm-linux-gnueabihf --with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69012
--- Comment #16 from Bernd Edlinger ---
(In reply to Nick Clifton from comment #15)
> Hi Guys,
>
> I have checked in Bernd's patch as it also fixes PR 69129. I think that
> this PR can also be closed now, although I am not sure if we need to
: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
Created attachment 37416
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37416&action=edit
reduced test case
Hi,
the attached small.cc creates an ICE when compiled with -fsanitize=un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69387
--- Comment #3 from Bernd Edlinger ---
Oh, now I see, you mean:
C++ Standard, Sec. 9.4.2 paragraph 4 says:
If a static data member is of const integral or const enumeration type, its
declaration in the class definition can specify a constant-ini
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69387
--- Comment #2 from Bernd Edlinger ---
Do you mean that is invalid?
class StatusCode
{
public:
static const int TEST_VALUE = 0x2;
};
I thought it is like defining
const int XXX = 123; which is actually only
a #define not a linker symbol.
I
++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
Hi,
the following example is miss-compiled at -O0
cat test.cc
class StatusCode
{
public:
static const int TEST_VALUE = 0x2;
};
typedef bool AssertionResult;
template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69134
Bernd Edlinger changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69012
--- Comment #13 from Bernd Edlinger ---
(In reply to Bernd Edlinger from comment #12)
>
> glibc-config:
> ../glibc-2.22/configure --prefix=/home/ed/gnu/mips-linux-gnu/mips-linux-gnu
> --build=mips-linux-gnu --disable-werror CC=mips-linux-gnu-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69034
--- Comment #3 from Bernd Edlinger ---
(In reply to Zdenek Sojka from comment #2)
> Created attachment 37217 [details]
> reduced testcase
>
> (In reply to Bernd Edlinger from comment #1)
> > Hi,
> >
> > I don't see any test case.
>
> Hello Ber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63669
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
../gcc-trunk/configure --prefix=/home/ed/gnu/mips-linux-gnu
--target=mips-linux-gnu --enable-languages=c,c++,fortran,ada
--host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59155
--- Comment #7 from Bernd Edlinger ---
Created attachment 37216
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37216&action=edit
proposed patch
this patch bootstraps cleanly and passes regression tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59155
--- Comment #6 from Bernd Edlinger ---
(In reply to Marc Glisse from comment #1)
> By the way, the following:
>
> double f(double x){
> asm volatile("":"+X"(x));
> return x;
> }
> double g(){
> return f(1.);
> }
>
> is rejected with:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69034
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68917
Bernd Edlinger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64402
--- Comment #3 from Bernd Edlinger ---
Created attachment 37172
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37172&action=edit
Patch to fix ICE and make interrupt restore r0
This patch fixes the ICE and makes interrupt functions
also res
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69012
--- Comment #11 from Bernd Edlinger ---
ok, now I see. try this:
Index: gcc/config/mips/mips.c
===
--- gcc/config/mips/mips.c (revision 231927)
+++ gcc/config/mips/mips.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69012
--- Comment #9 from Bernd Edlinger ---
(In reply to Paul Hua from comment #8)
> (In reply to Bernd Edlinger from comment #6)
> > (In reply to Paul Hua from comment #5)
> > > Created attachment 37115 [details]
> > > building command
> >
> > I'm u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69012
--- Comment #7 from Bernd Edlinger ---
FYI, I used:
../gcc-trunk/configure --prefix=/home/ed/gnu/mips64el-unknown-linux
--target=mips64el-unknown-linux --enable-languages=c --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69012
--- Comment #6 from Bernd Edlinger ---
(In reply to Paul Hua from comment #5)
> Created attachment 37115 [details]
> building command
I'm unable to reproduce.
What is your cross-compiler command line?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69012
--- Comment #3 from Bernd Edlinger ---
I will have a look, but please,
can you attach a preprocessed source for maxval_r4.c
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68917
--- Comment #3 from Bernd Edlinger ---
by the way, did you have also trouble to build the
libgcc multilib configuration or did you --disable-multilib?
this seems completely broken too...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64402
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68917
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68843
--- Comment #8 from Bernd Edlinger ---
(In reply to David from comment #7)
> Would a doc patch be appropriate too?
well, more difficult how to explain it right than to code it right,
meanwhile I added a sentence in english this to the patch:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10396
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59155
--- Comment #5 from Bernd Edlinger ---
Oh no! The X constraint allows just everything.
and combine combines everything that is OK for
check_asm_operands. But reg_overlap_mentioned_p
is not expecting anything that complicated.
How about:
Index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59155
--- Comment #4 from Bernd Edlinger ---
234r.ud_dce:
(insn 12 10 13 2 (set (reg:DF 93)
(plus:DF (reg:DF 91 [ xD.1775 ])
(reg:DF 90 [ xD.1777 ]))) t3.c:6 813 {*fop_df_comm_mixed}
(expr_list:REG_DEAD (reg:DF 91 [ xD.1775 ])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59155
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59181
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68187
--- Comment #3 from Bernd Edlinger ---
(In reply to David Malcolm from comment #2)
> Thanks; this is visible in full at:
> https://github.com/openssl/openssl/blob/master/crypto/engine/eng_lib.c#L116
>
> Looking at
> https://github.com/openssl/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68187
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68843
--- Comment #6 from Bernd Edlinger ---
How about this?
I think tt should fix both issues.
Index: reg-stack.c
===
--- reg-stack.c (Revision 231598)
+++ reg-stack.c (Arbeitskopie)
@@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68843
--- Comment #5 from Bernd Edlinger ---
and that's the next oddity:
cat t1.c
int test (double x, double y)
{
int r;
asm ("fist %0\t# %0 %1 %2" : "=r" (r) : "r" (x), "t" (y));
return r;
}
gcc -S t1.c -m32
t1.c: In function ‘test’:
t1.c:4:3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68843
--- Comment #4 from Bernd Edlinger ---
hmm, yes.
the registers are named "st" "st(1)" "st(2)" .. "st(7)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68843
--- Comment #2 from Bernd Edlinger ---
(In reply to Uroš Bizjak from comment #1)
> There are several non-intuitive rules that one has to follow to avoid ICEs
> with x87 asm operands. Just don't go down that path, there is only pain and
> suffer.
inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
Hi,
I have just played a bit with 80x87 fpu register constraints, and found an ICE:
cat t1.c
double test()
{
double x,y;
asm ("# %0 %1 %2" : "=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66131
--- Comment #1 from Bernd Edlinger ---
Note: the test case as-it-is, does no longer reproduce on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67756
Bernd Edlinger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67756
--- Comment #19 from Bernd Edlinger ---
ok, but now we have because of the warnings:
FAIL: gcc.target/arm/pr67756.c (test for excess errors)
I think something like this could fix it:
Index: pr67756.c
===
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67756
--- Comment #16 from Bernd Edlinger ---
(In reply to Vladimir Makarov from comment #13)
> (In reply to Bernd Edlinger from comment #11)
> > I must admit, that I don't know what I am doing here,
> > ... but this (completely untested) patch seems t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67756
--- Comment #15 from Bernd Edlinger ---
(In reply to Vladimir Makarov from comment #14)
> (In reply to Bernd Edlinger from comment #5)
>
> >
> > My patch from yesterday makes no difference here, but what's funny is,
> > that the set register wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67756
--- Comment #11 from Bernd Edlinger ---
I must admit, that I don't know what I am doing here,
... but this (completely untested) patch seems to fix the ICE:
(and at least my linux kernel compiles without ICE now)
--- lra-assigns.c.jj2015-07-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67756
--- Comment #7 from Bernd Edlinger ---
(In reply to ktkachov from comment #6)
> Perhaps a bisection to the revision that started this could shed some light
absolutely, but my computer powers are too limited for that. could you help?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67756
Bernd Edlinger changed:
What|Removed |Added
CC||vmakarov at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67756
--- Comment #4 from Bernd Edlinger ---
necessary compiler options to trigger the ICE: -O2 and -mapcs
arm-linux-gnueabihf-gcc -O2 -mapcs -S kernel-ice.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67037
--- Comment #4 from Bernd Edlinger ---
I believe that when we see this in testcase.c.232r.reload
73: [r166:SI++]=r142:SI#0
REG_DEAD r142:SI
REG_INC r149:SI
Inserting insn reload before:
153: r166:SI=[afp:SI+0x14f8]
Inser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67756
--- Comment #1 from Bernd Edlinger ---
Created attachment 36411
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36411&action=edit
preprocessed source file
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
arm-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/home/ed/gnu/arm-linux-gnueabihf-linux64/libexec/gcc/arm-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66236
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63602
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66747
--- Comment #3 from Bernd Edlinger ---
Created attachment 35902
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35902&action=edit
proposed patch
this slightly improved patch should fix it, could you give it a try?
Thanks,
Bernd.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66614
--- Comment #3 from Bernd Edlinger ---
I checked a few apps, and have not yet found any impact of the return
value of rtx_addr_can_trap_p_1 on the final code so far.
That means that this is probably only a low prio bug...
Regarding the LRA, I t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66614
--- Comment #2 from Bernd Edlinger ---
this is what I understand from lra in my own words:
lra () consists of a sequence of
for (;;) {
...
lra_eliminate (false, false);
/* Do inheritance only for regular algorithms.
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
Hi,
I have GCC compiled with this local patch in rtx_addr_can_trap_p_1
that should print a warning, when invalid frame offsets are encounterd:
Index: rtlanal.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64078
--- Comment #13 from Bernd Edlinger ---
Created attachment 35747
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35747&action=edit
Proposed Fix
that's what I think should fix the sporadic fall-out on both test cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047
--- Comment #23 from Bernd Edlinger ---
sorry, which patch are we discussing here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65902
--- Comment #5 from Bernd Edlinger ---
Well, I thought maybe it would not hurt to be more permissive...
At least math.h and stdlib.h include
which contains something like this:
#ifndef __cplusplus
typedef cyg_halbool bool;
# ifndef false
#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65902
--- Comment #3 from Bernd Edlinger ---
(In reply to Richard Earnshaw from comment #2)
> The standard headers should only be defining bool if stdbool.h has been
> included. So this looks more like a build environment error than a bug in
> GCC.
y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65905
Bernd Edlinger changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
Created attachment 35406
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35406&action=edit
precompiled sour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65902
--- Comment #1 from Bernd Edlinger ---
this would fix the regression:
--- libgcc/unwind-arm-common.inc.jj 2015-01-05 13:33:28.0 +0100
+++ libgcc/unwind-arm-common.inc2015-04-27 15:54:04.378469179 +0200
@@ -36,7 +36,7 @@
/*
: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
build for eCos fails in libgcc because sys-include/cyg/infra/cyg_type.h
typedef's bool and libgcc/unwind-arm-common.inc defines it too.
../gcc-5.1.0/configure --p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65067
--- Comment #13 from Bernd Edlinger ---
(In reply to Ramana Radhakrishnan from comment #12)
> fixed ?
yes, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64078
--- Comment #12 from Bernd Edlinger ---
The same could happen also with object-size-10.c:
https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01293.html
FAIL: c-c++-common/ubsan/object-size-10.c -O2 execution test
FAIL: c-c++-common/ubsan/obje
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64078
--- Comment #11 from Bernd Edlinger ---
I don't know if that is a bug or not.
I see that -fpic does not inline f2 and f3.
The two messages seem to be always missing when
not inlined...
So, how about this:
Index: gcc/testsuite/c-c++-common/ubs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64078
--- Comment #10 from Bernd Edlinger ---
Hmmm, the other issue is this:
g++ -g -O2 -fsanitize=undefined object-size-9.c
./a.out
object-size-9.c:21:11: runtime error: load of address 0x7fffaad34acc with
insufficient space for an object of type 'c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64078
--- Comment #9 from Bernd Edlinger ---
this should avoid the random '' issue:
Index: object-size-9.c
===
--- object-size-9.c(revision 222007)
+++ object-size-9.c(working cop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64078
--- Comment #8 from Bernd Edlinger ---
(In reply to vries from comment #7)
> Created attachment 35215 [details]
> relevant bit of gcc.log
>
> > Next time I encounter it, I'll try to post the full FAIL message
>
> I ran into this while testing a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997
--- Comment #18 from Bernd Edlinger ---
(In reply to Bernd Edlinger from comment #17)
> (In reply to Andrew Pinski from comment #16)
> > This testcase fails on aarch64 when SLOW_UNALIGNED_ACCESS is true.
>
> hmm, yes.
>
> there are targets that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65646
--- Comment #5 from Bernd Edlinger ---
gcc/testsuite/ChangeLog missing?
: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Hi,
on current trunk (snapshot gcc-5-20150329, r221765)
the following file causes an ICE:
$ cat test.cpp
const_iterator
#include
$ g++ test.cpp
lots of warnings/errors, and then:
/home/ed/gnu/install/include/c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63683
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65457
Bernd Edlinger changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65457
Bernd Edlinger changed:
What|Removed |Added
Target||arm-linux-gnueabihf
Component|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65449
--- Comment #3 from Bernd Edlinger ---
Yes, but that is not the fault of the strict volatile code path any more.
For bit-fields this redundant read is exactly what AAPCS demands:
"7.1.7.5 Volatile bit - fields preserving number and width of con
501 - 600 of 958 matches
Mail list logo
