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=85904
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
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=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();
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53325
--- Comment #5 from Sebastian Huber
2012-11-28 08:09:47 UTC ---
It is fixed on GCC 4.8. GCC 4.6 and 4.7 are still open.
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00939.html
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
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=69617
--- Comment #2 from Sebastian Huber ---
Yes, sorry, I meant the load with reservation and store conditional
instructions.
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
: 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=81070
--- Comment #1 from Sebastian Huber ---
The native GNAT is:
gnat --version
GNAT 7.1.1 20170530 [gcc-7-branch revision 248621]
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
: 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=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
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 #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 #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 #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 #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
Sebastian Huber changed:
What|Removed |Added
CC||jakub at redhat dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78029
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
: 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=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.
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 #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 #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 #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
Sebastian Huber changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=
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=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
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 #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 #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 #11 from Sebastian Huber ---
Thanks for your kind help. Would it be possible to back port this to GCC 6
also?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60040
--- Comment #6 from Sebastian Huber ---
GCC 4.9.0 20140407 with the proposed patch fixes the problem for me.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
With a GCC 4.8 and 4.9 snapshot from 2014-04-14 I get an ICE during GCC build:
make[4]: Entering directory
`/scratch/git-build/b-gcc-git-powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60839
Sebastian Huber changed:
What|Removed |Added
Target||powerpc-rtems4.11
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60839
--- Comment #3 from Sebastian Huber ---
Created attachment 32599
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32599&action=edit
Pre-processed source of libgcc2.c
Command line without pre-processor relevant options:
xgcc -mcpu=8540 -g -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60839
Sebastian Huber changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Should work with C++? I use GCC as a cross-compiler for RTEMS
targets. RTEMS uses Newlib as C library. I ported the FreeBSD version of
to Newlib and use this successfully with C/C++ and GCC pre-4.9
versions.
http
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102
--- Comment #2 from Sebastian Huber ---
Sorry, but my test run on 2014-04-17 used --disable-multilib, so it didn't
build the multilib in question. So the problem was also present on 2014-04-17.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
--- Comment #2 from Sebastian Huber ---
So I cannot use C libraries using atomics with C++ on GCC targets? With
FreeBSD and clang this works fine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
--- Comment #4 from Sebastian Huber ---
It is surely not the fault of GCC developers that C and C++ diverge more and
more, but for embedded systems developers this is quite painful.
It is clear that you cannot use C++ header files from C. So if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
--- Comment #9 from Sebastian Huber ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Sebastian Huber from comment #4)
> > It is clear that you cannot use C++ header files from C. So if you want to
> > provide a library intended fo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
Sebastian Huber changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102
--- Comment #4 from Sebastian Huber ---
I had to go back a bit to find a problematic commit:
3983036a8b6b2710c5194f21507819a73553 is the first bad commit
commit 3983036a8b6b2710c5194f21507819a73553
Author: chrbr
Date: Tue May 21 07:48:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102
Sebastian Huber changed:
What|Removed |Added
CC||hjl at gcc dot gnu.org
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102
--- Comment #11 from Sebastian Huber ---
(In reply to Richard Biener from comment #10)
> Please specify more exactly the affected target triplet and specify a
> known-to-work version.
>
> Marking as regression for now.
A target is for example "
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=35006&action=edit
Test program.
The task untied test case
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
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.
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
Sebastian Huber changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
The compiler doesn't generate gprel load/store operations for variables
external to the translation unit (this is unlike the PowerPC target for
example). Consider the following test case:
gprel
ty: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
avr-rtems4.11-gcc -fpreprocessed -w -mmcu=atmega128 -O2 -s test.i -o /dev/null
test.i: In function 'rtems_fdisk_recycle_segment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60040
--- Comment #1 from Sebastian Huber ---
Created attachment 32024
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32024&action=edit
Test case.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59150
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59150
--- Comment #7 from Sebastian Huber ---
Your patch fixed the problem on arm-rtems:
http://gcc.gnu.org/ml/gcc-testresults/2014-02/msg00303.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60040
--- Comment #3 from Sebastian Huber ---
With avr-rtems4.11-gcc (GCC) 4.9.0 20140218 (experimental) I still get the
error:
avr-rtems4.11-gcc -fpreprocessed -w -mmcu=atmega128 -O2 -s test.i -o /dev/null
test.i: In function 'rtems_fdisk_recycle_segm
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=59710
Sebastian Huber changed:
What|Removed |Added
Known to work||5.0
--- Comment #3 from Sebastian Hube
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Building the arm-rtems target leads to this ICE:
/scratch/git-build/b-gcc-git-arm-rtems4.11/./gcc/xgcc
-B/scratch/git-build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63224
--- Comment #2 from Sebastian Huber ---
I think this is a false positive warning.
The relevant code is:
for ( i = 0;
name_size
&& (c = msdos_get_valid_utf16_filename_character ( long_name[i])
);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63224
--- Comment #5 from Sebastian Huber ---
Which dump?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63224
--- Comment #7 from Sebastian Huber ---
I reduced the test case using the delta tool to:
void foo(void);
void bar(int s, int *a)
{
int i;
int c;
for (i = 0; s != 0 && (c = a[i]); ++i) {
}
if (s == 2 &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63224
--- Comment #8 from Sebastian Huber ---
Actually the for loop is not necessary.
int bar(int s, int *a)
{
int c;
int r;
r = s != 0 && (c = a[s]);
if (s == 2 && c == 0) {
} else if (s != 0) {
return 0;
}
retu
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=68910
--- Comment #1 from Sebastian Huber ---
Code generation for leon3 is also quite bad.
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=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
--- 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=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 #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
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
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
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
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=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=65779
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
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
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66854
Sebastian Huber changed:
What|Removed |Added
CC||meissner at linux dot
vnet.ibm.com
--
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=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(
++
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=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.
: 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=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
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 #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 #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.
nedTo: unassig...@gcc.gnu.org
ReportedBy: sebastian.hu...@embedded-brains.de
Target: arm-rtems4.11
Exact GCC version is: 4.6.0-RC-20110321.
/opt/rtems-4.11-custom/lib/gcc/arm-rtems4.11/4.6.0/thumb/libgcc.a(bpabi.o): In
function `__gnu_ldivmod_helper':
/home/sh/archive/gc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48239
Sebastian Huber changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
: unassig...@gcc.gnu.org
ReportedBy: sebastian.hu...@embedded-brains.de
Target: powerpc-rtems4.11-gcc
Created attachment 23977
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23977
C source code corresponding to the assembler code.
Creating an assembler file with
powe
101 - 200 of 210 matches
Mail list logo
