https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93543
--- Comment #4 from Sebastian Huber ---
(In reply to David Malcolm from comment #3)
> Thanks. Does the patch in comment #1 fix it for you?
I tested the patch on FreeBSD 12.1 with LLVM 8.0.1 and it fixes the issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93543
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88789
Sebastian Huber changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #33 from Sebastian Huber ---
(In reply to Eric Gallager from comment #32)
> (In reply to Martin Liška from comment #31)
> > Can the bug be marked as resolved?
>
> WAITING on a reply.
From my point of view it is fixed
I guess since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66032
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
I tried to build a native GCC with Ada support with a long build and source
directory:
pwd
/home/user
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643
--- Comment #5 from Sebastian Huber ---
I think the basic problem is that the LD --wrap feature works only with
undefined symbols references and not relocations:
See also:
https://www.sourceware.org/ml/binutils/2019-01/msg00204.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88789
--- Comment #2 from Sebastian Huber ---
I am not an epiphany expert. I just noticed this while testing the GCC builds
for RTEMS.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
Build fails in libstdc++ currently:
libtool: compile:
/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
--- Comment #29 from Sebastian Huber ---
Just for reference some numbers for GCC 7.4.0 and GCC 9.0.0 20190104:
sparc-rtems5-gcc --version
sparc-rtems5-gcc (GCC) 7.4.0 20181206 (RTEMS 5, RSB
ddba5372522da341fa20b2c75dfe966231cb6790, Newlib
df6915
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87683
--- Comment #1 from Sebastian Huber ---
It seems it has nothing to do with the non-null attribute. This function
void d(void)
{
int s;
void *p;
s = posix_memalign(&p, 16, 16);
if (s != 22) {
a();
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
I use this macro since 2016 to prevent certain compiler optimizations:
#define OBFUSCATE_VARIABLE(var) __asm__("" :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85904
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83090
--- Comment #2 from Sebastian Huber ---
I was able to build GCC ab053afeec0450e64568a7a0d50d0e9a5ece2787 (20180116).
ty: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
Created attachment 43113
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43113&action=edit
Makefile t
NCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
Created attachment 43112
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43112&action
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
Created attachment 43097
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43097&action=edit
Test case.
/home/sh/b-gcc-sh/./g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83761
--- Comment #3 from Sebastian Huber ---
Created attachment 43096
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43096&action=edit
Test case.
/home/sh/b-gcc-bfin/./gcc/xgcc -B/home/sh/b-gcc-bfin/./gcc/ -c sum_c8.i -O2 -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83761
--- Comment #1 from Sebastian Huber ---
Created attachment 43086
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43086&action=edit
Makefile to build the cross GCC
Use
make clone
make install/bin/bfin-rtems5-ld
make install/bin/bfin-rtems5-
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
make[4]: Entering directory
`/run/user/10351/b-gcc-bfin/bfin-rtems5/libgfortran'
/bin/sh ./libtool --tag=CC --mode=compile
/run/user/10351/b-gcc-bfin/./gcc/xgcc -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83681
Sebastian Huber changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
NCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
I cannot build an epiphany-rtems5 Ada compiler:
/run/user/10351/b-gcc-epiphany/./gcc/xgcc
-B/run/
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
Created attachment 43016
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43016&action=edit
Test program.
m32c-rtems5-gcc -O2 test.i
during R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83090
Sebastian Huber changed:
What|Removed |Added
CC||lekernel at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
--- Comment #15 from Sebastian Huber ---
(In reply to Sebastian Huber from comment #14)
> (In reply to Peter Bergner from comment #13)
> > (In reply to Sebastian Huber from comment #12)
> > > (In reply to Peter Bergner from comment #9)
> > > [...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
--- Comment #14 from Sebastian Huber ---
(In reply to Peter Bergner from comment #13)
> (In reply to Sebastian Huber from comment #12)
> > (In reply to Peter Bergner from comment #9)
> > [...]
> > > Here, you can see that on ELFv2, we always assu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
--- Comment #12 from Sebastian Huber ---
(In reply to Peter Bergner from comment #9)
[...]
> Here, you can see that on ELFv2, we always assume HW FP regs are avialable,
> because we're forcing usage of HW FP registers (FP_ARG_RETURN, ie, f1, aka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
Sebastian Huber changed:
What|Removed |Added
Target|powerpc-rtems5 |powerpc64le-unknown-linux-g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
--- Comment #6 from Sebastian Huber ---
(In reply to Peter Bergner from comment #5)
> (In reply to Sebastian Huber from comment #4)
> > If I remove the -msoft-float, the two example source files compile
> > (-mno-altivec seems to cause no harm).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
--- Comment #4 from Sebastian Huber ---
(In reply to Peter Bergner from comment #3)
> (In reply to Sebastian Huber from comment #2)
> > Is -msoft-float supported on 64-bit PowerPC? It is not important for us. I
> > just copied the 32-bit multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
--- Comment #2 from Sebastian Huber ---
(In reply to Peter Bergner from comment #1)
> Is the insn you're dying with contain FP operands? I know the backend for
> 64-bit PowerPC assumes/requires 64-bit FP hardware is available and since
> you're
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
I added support for the 64-bit PowerPC some months ago using a variant of the
ELFv2 ABI. I don't know which kind of long double support I use on this t
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
The following test program
static int vector_to_bit(int vector)
{
return 1U << (vector & 0x1fU);
}
static vo
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
The following test program
static int vector_to_bit(int vector)
{
return 1U << (vector & 0x1fU);
}
static vo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81070
--- Comment #1 from Sebastian Huber ---
The native GNAT is:
gnat --version
GNAT 7.1.1 20170530 [gcc-7-branch revision 248621]
: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
On GCC 7.1 branch (34df49547806512c6e1549a58048f161f5fa42bc) I get the
following error while building the Ada run-time support:
make[5]: 's-inmaop.o' is up to date.
/build/git-b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694
Sebastian Huber changed:
What|Removed |Added
CC||jakub at redhat dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694
--- Comment #12 from Sebastian Huber ---
Its strange that it is so hard to reproduce. Maybe it has something to do with
the default architecture version.
It fails with:
-mthumb -O2 -ftls-model=local-exec -march=armv4t
-mthumb -O2 -ftls-model=l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694
--- Comment #9 from Sebastian Huber ---
I did a fresh git clone today on gcc113 of the GCC compile farm. I built an
arm-linux-gnueabihf GCC:
./install/bin/arm-linux-gnueabihf-gcc --version --verbose
Using built-in specs.
COLLECT_GCC=./install/bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694
--- Comment #7 from Sebastian Huber ---
Are you able to reproduce the problem with this information? You need the
attached test case. The arm-eabi GCC build itself works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694
--- Comment #6 from Sebastian Huber ---
(In reply to ktkachov from comment #5)
> I cannot reproduce with that revision.
> Again, how do you configure your gcc.
> What is the output of arm-eabi-gcc -v that you built?
arm-eabi-gcc -v
Using built-i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694
--- Comment #4 from Sebastian Huber ---
(In reply to ktkachov from comment #3)
> I can't reproduce on an arm-none-eabi compiler built with RTL checking. Do
> you pass any particular --with-arch/cpu/fpu/float options?
I built an arm-eabi-gcc usin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694
--- Comment #2 from Sebastian Huber ---
(In reply to ktkachov from comment #1)
> what is the configuration you're trying to build?
A bare metal ARM EABI compiler should reproduce the problem. I try to build the
arm-rtems4.12-gcc with a patch to
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
Created attachment 40264
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40264&action=edit
Test case
The attached test case generates an ICE during GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
--- Comment #11 from Sebastian Huber ---
Thanks for your kind help. Would it be possible to back port this to GCC 6
also?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
--- Comment #8 from Sebastian Huber ---
(In reply to Chung-Lin Tang from comment #7)
> (In reply to Sebastian Huber from comment #6)
> > (In reply to Chung-Lin Tang from comment #5)
> > > > I checked the code generation on some targets for the te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
--- Comment #6 from Sebastian Huber ---
(In reply to Chung-Lin Tang from comment #5)
> > I checked the code generation on some targets for the test case above. The
> > arm, bfin, epiphany, i386, lm32, m68k, mips, moxie, sh, v850 targets
> > gener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
--- Comment #4 from Sebastian Huber ---
(In reply to Chung-Lin Tang from comment #3)
> (In reply to Sebastian Huber from comment #2)
> > (In reply to Chung-Lin Tang from comment #1)
> > > Sebastian, I'm not sure what your problem is. The atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
--- Comment #2 from Sebastian Huber ---
(In reply to Chung-Lin Tang from comment #1)
> Sebastian, I'm not sure what your problem is. The atomics in nios2 are
> implemented by __sync_* functions placed in libgcc. The built-in function
> expansion
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
Some Nios II variants lack support for atomic operations in hardware. The GCC
Nios II support generates in this case non-standard __sync_* function calls,
e.g.
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78199
--- Comment #1 from Sebastian Huber ---
A native 64-bit PowerPC GCC built on
uname -a
Linux gcc2-power8.osuosl.org 3.17.4-301.fc21.ppc64le #1 SMP Mon Dec 1 07:51:01
UTC 2014 ppc64le ppc64le ppc64le GNU/Linux
generates this
gcc -O2 -ftls-model=
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
The following test case:
extern __thread int i;
extern int s;
int fi(void)
{
return i;
}
int fs(void)
{
return s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168
Sebastian Huber changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168
--- Comment #11 from Sebastian Huber ---
(In reply to Segher Boessenkool from comment #10)
> Doesn't fail with powerpc-rtems4.12 either. Are you sure you built trunk?
> A clean build?
I tested again today using:
commit 89bcfdabe78607bf83aa58e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168
--- Comment #8 from Sebastian Huber ---
On RTEMS I think -mspe is enabled for -mcpu=8540.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168
--- Comment #7 from Sebastian Huber ---
A git bisect indicates this as the bad commit:
commit 14fdd09f470dea253089d6a5b27d7a2c3ab7d67a
Author: segher
Date: Wed Oct 12 15:34:39 2016 +
rs6000: Separate shrink-wrapping
This impleme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168
--- Comment #3 from Sebastian Huber ---
My configure command line:
configure --target=powerpc-rtems4.12 --verbose --with-newlib
--disable-libstdcxx-pch --disable-nls --disable-lto --disable-plugin
--enable-languages=c
Should also work with a ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168
--- Comment #2 from Sebastian Huber ---
(In reply to Andrew Pinski from comment #1)
> Most likely a dup of bug 78029.
I am not sure. I get the ICE with the latest GCC which includes the fix for bug
78029.
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
Created attachment 39926
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39926&action=edit
Test case
/bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78029
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71957
Sebastian Huber changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71957
--- Comment #4 from Sebastian Huber ---
(In reply to Richard Biener from comment #3)
> On a second look the testcase looks invalid as it invokes a virtual function
> via C on an object of type C. Why do you think doing this is valid?
I try to g
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
The following test case produces wrong code with GCC 6. The problem is at least
visible on x86, ARM, SPARC and PowerPC.
class A {
public:
A(int);
};
template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
--- Comment #25 from Sebastian Huber ---
With GCC 6.1 there is now only a slight increase in code size compared to GCC
4.9. I am not sure if there is anything left to do on this PR.
sparc-rtems4.11-gcc --version
sparc-rtems4.11-gcc (GCC) 4.9.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69617
--- Comment #2 from Sebastian Huber ---
Yes, sorry, I meant the load with reservation and store conditional
instructions.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
On the PowerPC/e6500 elemental synchronization operations should be used for
acquire/release barriers. Currently a lwsync is used
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
The PowerPC/e6500 support lacks support for the load/store byte/halfword with
decoration indexed instructions:
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
--- Comment #12 from Sebastian Huber ---
New numbers for SPARC and PowerPC (rtems4.12-gcc 6.0.0 20160127):
sparc-rtems4.11-gcc -c -O2 -o vprintk.4.11.o vprintk.i
sparc-rtems4.12-gcc -c -O2 -o vprintk.4.12.o vprintk.i
size vprintk.4.11.o
text
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69027
--- Comment #2 from Sebastian Huber ---
I have an admittedly quite exotic use case where it hurts.
I changed a switch statement to adaptor functions in RTEMS to avoid dead code,
e.g.
https://git.rtems.org/rtems/diff/cpukit/score/src/threadhandl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
--- Comment #4 from Sebastian Huber ---
I did a very rough check to see which code is faster on the PSIM/GDB simulator
using the following input data:
void printk(const char *fmt, ...)
{
va_list ap;
va_start(ap, fmt);
vprintk(fmt, ap);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
--- Comment #2 from Sebastian Huber ---
Ok, with -Os I don't have the problem:
sparc-rtems4.11-gcc -c -Os -o vprintk.4.11.o vprintk.i
sparc-rtems4.12-gcc -c -Os -o vprintk.4.12.o vprintk.i
size vprintk.4.11.o
textdata bss dec
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
Created attachment 37274
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37274&action=edit
Test case.
This is quite an increase of the code size for the attached te
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
Consider the following test case:
int i(void);
int f(void)
{
return i();
}
int g(int (*j)(void))
{
return (*j)();
}
GCC generates on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68910
--- Comment #14 from Sebastian Huber ---
(In reply to Eric Botcazou from comment #13)
> Thanks for reporting the problem.
Thanks for the quick fix.
The stack frame is still larger than necessary at least on the -mcpu=cypress
and -mcpu=leon3 tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68910
--- Comment #9 from Sebastian Huber ---
In case I revert (e.g. double revert) to enable the LRA for SPARC
commit a28f6dc56909fc35dd83d4364bc68c69e2450a51
Author: davem
Date: Tue Sep 22 03:52:45 2015 +
Revert LRA SPARC changes for now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68910
--- Comment #6 from Sebastian Huber ---
(In reply to Eric Botcazou from comment #5)
> I have the huge stack frame with the 4.9.x compiler too so the spilling
> effect itself is probably not new.
Yes, sorry for imprecise known-to-work information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66867
--- Comment #3 from Sebastian Huber ---
clang 3.7 generates optimal code on x86 in both cases:
.text
.file "test.c"
.globl f
.align 16, 0x90
.type f,@function
f:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68910
Sebastian Huber changed:
What|Removed |Added
Known to fail||6.0
--- Comment #2 from Sebastian Hube
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68910
--- Comment #1 from Sebastian Huber ---
Code generation for leon3 is also quite bad.
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
Created attachment 37036
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37036&action=edit
Test case.
The code for the SHA512_Transform() func
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408
--- Comment #9 from Sebastian Huber ---
(In reply to Jonathan Wakely from comment #8)
> There's no need to test on linux, I can do that myself. If it works on your
> non-pthreads target I'll commit your patch.
Here it works fine:
https://lists.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408
--- Comment #7 from Sebastian Huber ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Sebastian Huber from comment #4)
> > Sorry, I should have linked my patch:
> >
> > https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00028.html
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408
--- Comment #5 from Sebastian Huber ---
(In reply to Sebastian Huber from comment #4)
> I think the your second version doesn't work in case the types are equal, it
> looks similar to my first attempt to fix this which didn't work on Linux.
Ple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408
--- Comment #4 from Sebastian Huber ---
Sorry, I should have linked my patch:
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00028.html
I think the your second version doesn't work in case the types are equal, it
looks similar to my first attemp
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
The problem is in in:
[...]
#if _GTHREAD_USE_MUTEX_TIMEDLOCK
template
class __timed_mutex_impl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #2 from Sebastian Huber ---
Indeed -std=gnu++98 gets rid of this error. So this is working as intended for
C++11 and later? This is really nice in combination with defines and macros
that use ( ) around its content.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
The following test case fails on x86_64-pc-linux-gnu, powerpc-rtems,
sparc-rtems:
struct s {
int i;
};
register struct s *reg __asm__( "1" );
int f(void)
{
int i;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66867
--- Comment #1 from Sebastian Huber ---
This problem is also present on x86. The depreated
__sync_bool_compare_and_swap() produces better code.
#include
void f(atomic_uint *a)
{
unsigned int e = 0;
atomic_compare_exchange_strong_explicit(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66854
--- Comment #4 from Sebastian Huber ---
(In reply to Michael Meissner from comment #3)
> Created attachment 35978 [details]
> Proposed patch to fix the problem
>
> I believe this patch fixes the problem. I was able to build libgcc with
> this p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66854
Sebastian Huber changed:
What|Removed |Added
CC||meissner at linux dot
vnet.ibm.com
--
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
At least on ARM and PowerPC for the following test case
#include
void f(atomic_uint *a)
{
unsigned int e = 0
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
make[4]: Entering directory
`/scratch/git-build/b-gcc-git-powerpc-rtems4.11/powerpc-rtems4.11/m403/libgcc'
# If this is th
iority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
CC: jakub at gcc dot gnu.org
It seems that is not available with -fopenmp:
stdatomic.h:40:1: sorry, unimplemented: '_Atomic' with OpenMP
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65385
Sebastian Huber changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65386
--- Comment #1 from Sebastian Huber ---
Created attachment 35009
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35009&action=edit
Test program.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65385
--- Comment #1 from Sebastian Huber ---
Created attachment 35008
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35008&action=edit
Test program.
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
CC: jakub at gcc dot gnu.org
Created attachment 35007
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35007&action=edit
Test program.
The task final test case of the
1 - 100 of 210 matches
Mail list logo
