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=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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56561
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53325
--- Comment #7 from Sebastian Huber
2013-03-20 08:09:50 UTC ---
It is also fixed in the GCC 4.6 and 4.7 branches.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55994
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56771
--- Comment #9 from Sebastian Huber
2013-04-03 15:23:29 UTC ---
(In reply to comment #8)
> Patch committed to 4.7, 4.8 and SVN head.
>
> Closing.
Can you please commit this also to the 4.6 branch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
--- Comment #70 from Sebastian Huber
2013-04-05 07:15:34 UTC ---
(In reply to comment #69)
> (In reply to comment #68)
> > Is this problem resolved? The status is still set to "NEW" but "known to
> > work"
> > shows that it either has be
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sebastian.hu...@embedded-brains.de
Created attachment 28513
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28513
Pre-processed C++ test f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55033
Sebastian Huber changed:
What|Removed |Added
Component|target |c++
--- Comment #1 from Sebas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55033
--- Comment #2 from Sebastian Huber
2012-10-23 15:03:37 UTC ---
#0 default_elf_select_section (decl=0x772b92d0, reloc=0, align=32) at
/home/sh/archive/gcc-git/gcc/varasm.c:6251
#1 0x00c57d4e in get_constant_section (align=,
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sebastian.hu...@embedded-brains.de
Created attachment 28518
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28518
Sample code
The attac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55058
--- Comment #2 from Sebastian Huber
2012-10-24 16:12:39 UTC ---
(In reply to comment #1)
> can you reduce it to get rid of all the code that doesn't affect the failure?
I already reduced it quite a lot, but I try harder tomorrow.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55058
--- Comment #3 from Sebastian Huber
2012-10-25 11:43:09 UTC ---
Created attachment 28527
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28527
Reduced smaple code.
This is the offending code reduced to the minimum. The error is no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55058
Sebastian Huber changed:
What|Removed |Added
Attachment #28518|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54883
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55058
Sebastian Huber changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
---
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sebastian.hu...@embedded-brains.de
Created attachment 28573
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28573
Test case.
The test c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54883
--- Comment #2 from Sebastian Huber
2012-10-30 14:16:05 UTC ---
Known to work GCC 4.0.4, 4.1.2, and 4.2.4:
echo "namespace { enum E { E1 }; } void f(E e) { }" | tee a.c b.c
namespace { enum E { E1 }; } void f(E e) { }
/scratch/install-g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55033
--- Comment #4 from Sebastian Huber
2012-11-06 13:18:15 UTC ---
(In reply to comment #3)
> Would this be testable on powerpc-apple-darwin8?
See also
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02051.html
The -mcpu=8540 -msdata=eab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55137
--- Comment #4 from Sebastian Huber
2012-11-06 15:31:42 UTC ---
(In reply to comment #2)
> The change is that now the struct is dynamically initialized rather than
> statically as it used to.
What do you mean with dynamically initialize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55137
--- Comment #5 from Sebastian Huber
2012-11-06 15:34:57 UTC ---
(In reply to comment #3)
> enum E { E1 = -1 + (int) (sizeof (int) - 1) };
> errors while it used to be accepted before.
> Dunno if that is valid or not.
> If it is valid, th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55137
--- Comment #7 from Sebastian Huber
2012-11-06 15:50:38 UTC ---
(In reply to comment #6)
> What I mean that for your testcase while you have s: .zero 8
> instead of s: .long 4, 16399, there is also dynamic initialization:
> movl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55137
--- Comment #9 from Sebastian Huber
2012-11-08 10:19:33 UTC ---
(In reply to comment #8)
> Created attachment 28624 [details]
> gcc48-pr55137.patch
>
> Untested patch.
I tried this patch and GCC Git version 5838c24a86ac8a8afe77285f22
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sebastian.hu...@embedded-brains.de
Target: powerpc-rtems4.11una
Created attachment 23349
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23349
Assembler code.
In the attached assembler file:
Line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47751
--- Comment #1 from Sebastian Huber
2011-02-15 13:12:52 UTC ---
Created attachment 23350
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23350
C source code corresponding to the assembler code.
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sebastian.hu...@embedded-brains.de
Target: powerpc-rtems4.11-gcc
Created attachment 23432
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23432
Sample code.
Using the embedded 64-bit float
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47751
--- Comment #3 from Sebastian Huber
2011-02-22 11:18:29 UTC ---
(In reply to comment #2)
> -mfloat-gprs=double or -mspe without -mabi=spe does not correspond to any
> standard ABI variant and is very likely to be broken.
Thanks for the hint. A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47847
--- Comment #1 from Sebastian Huber
2011-02-22 15:55:29 UTC ---
Adding the -mspe (in addition to -mabi=spe) option helped. It seems that only
few combinations of the -mcpu=8520, -mfloat-gprs=*, -mspe, and -mabi=spe flags
are well tested in GCC.
: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sebastian.hu...@embedded-brains.de
Target: powerpc-rtems4.11-gcc
Created attachment 23441
--> http://gcc.gnu.org/bugzilla/attachment.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55033
--- Comment #9 from Sebastian Huber ---
If I run the tests on gcc1-power7.osuosl.org (which is target
powerpc64-unknown-linux-gnu), then the PR55033 test case shows up as
UNSUPPORTED:
grep -r pr55033 .
./gcc/testsuite/gcc/gcc.sum:UNSUPPORTED: gcc
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Created attachment 30483
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30483&action=edit
Test case.
The 64-bit GPR save and restore sequence is broken and destroys the link
register s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865
Sebastian Huber changed:
What|Removed |Added
CC||amodra at gmail dot com
Known to w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45208
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865
--- Comment #3 from Sebastian Huber ---
(In reply to Alan Modra from comment #2)
> My guess is that it's this change
>
> -#define FIRST_SAVED_GP_REGNO 13
> +#define FIRST_SAVED_GP_REGNO (FIXED_R13 ? 14 : 13)
>
> messing with ool_adjust.
I use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865
--- Comment #5 from Sebastian Huber ---
(In reply to Alan Modra from comment #4)
> Created attachment 30489 [details]
> Fix ool_adjust
>
> Please verify that this fixes the problem
Yes, your patch fixes also the problem if applied to the 4.8 hea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865
--- Comment #6 from Sebastian Huber ---
(In reply to Sebastian Huber from comment #5)
> (In reply to Alan Modra from comment #4)
> > Created attachment 30489 [details]
> > Fix ool_adjust
> >
> > Please verify that this fixes the problem
>
> Yes,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865
--- Comment #7 from Sebastian Huber ---
(In reply to Sebastian Huber from comment #6)
> Test results:
>
> http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg00968.html
> http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg00980.html
http://gcc.gnu.or
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
The GCC C compiler generates a NULL pointer read and write for the atomic flag
test and set method in GCC 4.7, 4.8 and 4.9. The GCC C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58259
Sebastian Huber changed:
What|Removed |Added
Target|powerpc-eabi|powerpc-eabi, arm-eabi
Summa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58259
Sebastian Huber changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sebastian.hu...@embedded-brains.de
Target: arm-rtemseabi4.11
Created attachment 25028
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25028
Sample code.
Command line:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50106
--- Comment #1 from Sebastian Huber
2011-08-17 08:53:00 UTC ---
Created attachment 25029
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25029
arm-rtemseabi4.11-g++ -march=armv5t -mthumb -Os -S compiler1.test.ii -o
compiler1.test.eabi.Os.s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50106
--- Comment #2 from Sebastian Huber
2011-08-17 08:54:55 UTC ---
Created attachment 25030
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25030
arm-rtemseabi4.11-g++ -march=armv5t -mthumb -O2 -S compiler1.test.ii -o
compiler1.test.eabi.O2.s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50106
--- Comment #4 from Sebastian Huber
2011-08-22 09:43:39 UTC ---
Yes, this patch fixes the problem.
It is still not clear to me why we save the volatile registers r0, r1, and r2
at all. Also we restore r1, r2, and r3. Does this make sense? I t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49641
--- Comment #4 from Sebastian Huber
2011-08-22 11:00:07 UTC ---
The patch from Bernd Schmidt fixes the problem in my case. What is the status
of this patch?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41780
Sebastian Huber changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47856
--- Comment #1 from Sebastian Huber
2011-08-22 11:20:08 UTC ---
This bug is still present in GCC 4.6.1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47856
--- Comment #2 from Sebastian Huber
2011-08-22 12:03:41 UTC ---
This bug is also present in GCC 4.7.0 20110820.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49119
--- Comment #2 from Sebastian Huber
2011-08-22 12:19:24 UTC ---
This bug is not present in GCC 4.7.0 20110820. Does anyone know which commit
fixed this problem? Is it possible to integrate the fix in GCC 4.6?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49119
--- Comment #4 from Sebastian Huber
2011-08-23 15:01:59 UTC ---
Created attachment 25084
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25084
Generated assembler file.
Command line:
powerpc-rtems4.11-gcc -O2 -save-temps -fverbose-asm -c bs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49119
Sebastian Huber changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49119
Sebastian Huber changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #7 from Sebastian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49768
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
--- Comment #43 from Sebastian Huber
2011-09-06 07:45:29 UTC ---
How long will this middle to back end ping pong last until this bug is finally
fixed? It is now open since 2008.
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sebastian.hu...@embedded-brains.de
Target: powerpc-eabi-gcc
Created attachment 25229
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25229
Sample code.
Compiling the attached f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
--- Comment #46 from Sebastian Huber
2011-09-12 08:42:59 UTC ---
I guess the local patch will look like this:
http://gcc.gnu.org/ml/gcc/2011-07/msg00459.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49641
Sebastian Huber changed:
What|Removed |Added
Target|arm-rtemseabi4.11 |arm-eabi-gcc
Known to fail|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50106
Sebastian Huber changed:
What|Removed |Added
Target|arm-rtemseabi4.11 |arm-eabi-gcc
--- Comment #5 from Sebast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
--- Comment #52 from Sebastian Huber
2011-10-15 08:48:10 UTC ---
In GCC 4.6.2 20111014 (prerelease) the problem is still not fixed and
"arm-eabi-gcc -march=armv5t -mthumb -O2" produces wrong code. Please don't let
it slip through the next relea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50106
--- Comment #6 from Sebastian Huber
2011-10-18 14:19:55 UTC ---
Created attachment 25543
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25543
arm-eabi-g++ -march=armv5t -mthumb -Os -S compiler1.test.ii -o
compiler1.test.eabi.GCC-4.5.4.Os.s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50106
--- Comment #11 from Sebastian Huber
2011-10-20 11:07:09 UTC ---
Thank you very much. With this change the GCC 4.6.2-RC-20111019 produces now
correct code in this case.
I know understand why the unused volatile registers are saved and restored.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
--- Comment #53 from Sebastian Huber
2011-10-24 13:06:03 UTC ---
I tested the above patch proposed by Mikael Pettersson (from 2010-05-26, more
than one year ago) with GCC 4.6 20111021. It still fixes the test case
provided by Dave Murphy (from 2
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sebastian.hu...@embedded-brains.de
Target: arm-eabi-gcc
Compared to PowerPC the optimization for the attached test case is suboptimal.
Command line:
arm-eabi-gcc -O2 -march
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883
--- Comment #3 from Sebastian Huber
2011-10-27 11:55:32 UTC ---
Created attachment 25630
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25630
PowerPC assembler.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883
--- Comment #1 from Sebastian Huber
2011-10-27 11:54:31 UTC ---
Created attachment 25628
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25628
Sample code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883
--- Comment #2 from Sebastian Huber
2011-10-27 11:55:05 UTC ---
Created attachment 25629
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25629
ARM assembler.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883
--- Comment #5 from Sebastian Huber
2011-10-27 15:19:57 UTC ---
If we look at the function f (the function g is similar):
struct s {
int alignment;
unsigned char a;
unsigned char b;
unsigned char c;
unsigned char d;
};
unsigned f(stru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
--- Comment #54 from Sebastian Huber
2011-10-28 07:31:19 UTC ---
I tested with GCC 4.6.2 and the patch provided by Mikael Pettersson. It works
for -march=armv4t and -march=armv5t, but not for -march=armv5te:
--- test-armv5te.s 2011-10-28 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
--- Comment #58 from Sebastian Huber
2011-10-31 10:45:43 UTC ---
I tested Jiangning Liu's latest patch. With it GCC 4.6.2 produces valid code
for -march=armv4t, -march=armv5t, -march=armv5te, -march=armv6, and
-march=armv7-m. GCC 4.6.2 produces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
--- Comment #60 from Sebastian Huber
2011-11-09 09:00:26 UTC ---
Jiangning Liu thank you very much for your update.
The target milestone is currently 4.4.7. Are there plans to commit this fix
the the 4.4, 4.5, and 4.6 branches?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50329
Sebastian Huber changed:
What|Removed |Added
Attachment #25229|0 |1
is obsolete|
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
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=88789
--- Comment #2 from Sebastian Huber ---
I am not an epiphany expert. I just noticed this while testing the GCC builds
for RTEMS.
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=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
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=66032
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
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
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
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 #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
Sebastian Huber changed:
What|Removed |Added
Target|powerpc-rtems5 |powerpc64le-unknown-linux-g
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
--- 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 #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=83090
Sebastian Huber changed:
What|Removed |Added
CC||lekernel at gcc dot gnu.org,
: 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
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/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83681
Sebastian Huber changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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-
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83090
--- Comment #2 from Sebastian Huber ---
I was able to build GCC ab053afeec0450e64568a7a0d50d0e9a5ece2787 (20180116).
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
1 - 100 of 210 matches
Mail list logo
