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
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(, 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 <sebastian.hu...@embedded-brains.de> ---
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=edit
Makefile to build the
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=edit
Make
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=edit
Test case.
/home/sh/b-gcc-sh/./gcc/xgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83761
--- Comment #3 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
Created attachment 43096
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43096=edit
Test case.
/home/sh/b-gcc-bfin/./gcc/xgcc -B/home/sh/b-gcc-bfin/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83761
--- Comment #1 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
Created attachment 43086
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43086=edit
Makefile to build the cross GCC
Use
make clone
make install/bin/bfin-
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 -B/run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83681
Sebastian Huber <sebastian.hu...@embedded-brains.de> changed:
What|Removed |Added
Stat
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/user/10351
: 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=edit
Test program.
m32c-rtems5-gcc -O2 test.i
during RTL pass: pro_and_epilo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83090
Sebastian Huber <sebastian.hu...@embedded-brains.de> changed:
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
--- Comment #15 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
(In reply to Sebastian Huber from comment #14)
> (In reply to Peter Bergner from comment #13)
> > (In reply to Sebastian Huber from comment #12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
--- Comment #14 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
(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 #12 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
(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 us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
Sebastian Huber <sebastian.hu...@embedded-brains.de> changed:
What|Removed |Added
Target|powerpc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
--- Comment #6 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
(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 sourc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
--- Comment #4 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
(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 i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
--- Comment #2 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
(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/requir
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 target
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 <sebastian.hu...@embedded-brains.de> ---
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-build/b-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694
Sebastian Huber <sebastian.hu...@embedded-brains.de> changed:
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694
--- Comment #12 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
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=loca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694
--- Comment #9 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694
--- Comment #7 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
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 <sebastian.hu...@embedded-brains.de> ---
(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-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694
--- Comment #4 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
(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/c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694
--- Comment #2 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
(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
: 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=edit
Test case
The attached test case generates an ICE during GCC bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
--- Comment #11 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
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 <sebastian.hu...@embedded-brains.de> ---
(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)
> > &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
--- Comment #6 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
--- Comment #4 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
(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)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
--- Comment #2 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
(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_* func
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 <sebastian.hu...@embedded-brains.de> ---
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
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 <sebastian.hu...@embedded-brains.de> changed:
What|Removed |Added
Stat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168
--- Comment #11 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168
--- Comment #8 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
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 <sebastian.hu...@embedded-brains.de> ---
A git bisect indicates this as the bad commit:
commit 14fdd09f470dea253089d6a5b27d7a2c3ab7d67a
Author: segher <segher@138bc75d-0d04-0410-961f-82ee72b054a4>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168
--- Comment #3 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
My configure command line:
configure --target=powerpc-rtems4.12 --verbose --with-newlib
--disable-libstdcxx-pch --disable-nls --disable-lto --disable-plugin
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168
--- Comment #2 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
(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=edit
Test case
/build/git-buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78029
Sebastian Huber <sebastian.hu...@embedded-brains.de> changed:
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71957
Sebastian Huber <sebastian.hu...@embedded-brains.de> changed:
What|Removed |Added
Status|W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71957
--- Comment #4 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
(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.
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 <sebastian.hu...@embedded-brains.de> ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69617
--- Comment #2 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
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: ---
The PowerPC/e6500 support lacks support for the load/store byte/halfword with
decoration indexed instructions:
#include
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
--- Comment #12 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779
Sebastian Huber <sebastian.hu...@embedded-brains.de> changed:
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69027
--- Comment #2 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
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.rte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
--- Comment #4 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
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_l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
--- Comment #2 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
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.
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=edit
Test case.
This is quite an increase of the code size for the attached test case.
sp
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68910
--- Comment #14 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68910
--- Comment #9 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
In case I revert (e.g. double revert) to enable the LRA for SPARC
commit a28f6dc56909fc35dd83d4364bc68c69e2450a51
Author: davem <davem@138bc75d-0d04-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68910
--- Comment #6 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
(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.
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=edit
Test case.
The code for the SHA512_Transform() function is very p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68910
Sebastian Huber <sebastian.hu...@embedded-brains.de> changed:
What|Removed |Added
Known t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68910
--- Comment #1 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
Code generation for leon3 is also quite bad.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66867
--- Comment #3 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
clang 3.7 generates optimal code on x86 in both cases:
.text
.file "test.c"
.globl f
.align 16, 0x90
.type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363
Sebastian Huber <sebastian.hu...@embedded-brains.de> changed:
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408
--- Comment #7 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
(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/bugzilla/show_bug.cgi?id=67408
--- Comment #9 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
(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 commi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408
--- Comment #5 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
(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 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408
--- Comment #4 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
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
: 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
++
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;
i = reg-i;
i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #2 from Sebastian Huber sebastian.hu...@embedded-brains.de ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66867
--- Comment #1 from Sebastian Huber sebastian.hu...@embedded-brains.de ---
This problem is also present on x86. The depreated
__sync_bool_compare_and_swap() produces better code.
#include stdatomic.h
void f(atomic_uint *a)
{
unsigned int e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66854
--- Comment #4 from Sebastian Huber sebastian.hu...@embedded-brains.de ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66854
Sebastian Huber sebastian.hu...@embedded-brains.de changed:
What|Removed |Added
CC
: 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 stdatomic.h
void f(atomic_uint *a)
{
unsigned int e
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 the top
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 stdatomic.h is not available with -fopenmp:
stdatomic.h:40:1: sorry, unimplemented: '_Atomic' with OpenMP
typedef _Atomic
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
CC: jakub at gcc dot gnu.org
Created attachment 35006
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35006action=edit
Test program.
The task untied test case of the OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65385
--- Comment #1 from Sebastian Huber sebastian.hu...@embedded-brains.de ---
Created attachment 35008
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35008action=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=35007action=edit
Test program.
The task final test case of the OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65386
--- Comment #1 from Sebastian Huber sebastian.hu...@embedded-brains.de ---
Created attachment 35009
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35009action=edit
Test program.
1 - 100 of 209 matches
Mail list logo
