--- Comment #24 from rask at sygehus dot dk 2007-06-24 13:04 ---
Subject: Re: [4.3 Regression] Segmentation
fault in build_classic_dist_vector_1()@tree-data-ref.c:2700
On Sun, Jun 24, 2007 at 02:50:37PM +0200, Sebastian Pop wrote:
> 2007-06-24 Sebastian Pop <
--- Comment #13 from rask at sygehus dot dk 2007-06-24 17:38 ---
I updated to revision 125983, which hasn't changed anything as far as I can
tell.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC target triplet: mipsisa64-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32495
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC target triplet: powerpc-unknown-eabisim
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32498
--- Comment #14 from rask at sygehus dot dk 2007-06-27 00:35 ---
Notice in comment 10 that there is no optimization flag. Just -O1 is enough to
make the reload failure go away. I'll see what the libstdc++ people have to say
about that.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #16 from rask at sygehus dot dk 2007-06-27 19:15 ---
What's wrong with the patch at the top of comment 9? FWIW, I can now build the
m32c after this configure command:
$ /n/12/rask/src/all/configure --target=m32c-unknown-elf
--enable-languages=c,c++ --enable-cxx-flag
--- Comment #18 from rask at sygehus dot dk 2007-06-27 19:48 ---
It has not been committed yet because I feared that it was causing the reload
failure. I have now verified that the reload failure still happens with a
pre-dataflow checkout, so I'll submit the patch. I think
--- Comment #17 from rask at sygehus dot dk 2007-06-29 21:10 ---
Fixed for both m32c and avr, so closing.
--
rask at sygehus dot dk changed:
What|Removed |Added
dTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: v850-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32558
--- Comment #1 from rask at sygehus dot dk 2007-07-01 09:37 ---
Additionally, the asm output has problems around the edges (seen in _pack_df):
mov 9218868437227405312,r14 # 395 *movdi_internal/1 [length
= 4]
mov 0,r15
--
rask at sygehus dot dk changed
--- Comment #2 from rask at sygehus dot dk 2007-07-01 10:01 ---
Created an attachment (id=13810)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13810&action=view)
First attempt at a patch
The attached patch makes the v850 build on x86_64. There are a few regressions
(when
--- Comment #13 from rask at sygehus dot dk 2007-07-01 19:52 ---
This has regressed quite badly. Here's what we get with
-O2 -fomit-frame-pointer -m32 -march=pentium4:
fl:
movzbl %al, %eax # 21*zero_extendqisi2_movzbw[length
= 3]
movlx,
--- Comment #3 from renard at nospam dot dk 2007-07-03 10:59 ---
I get what I think is the exact same problem:
mm/slab.c:2243: error: expected an SSA_NAME object
mm/slab.c:2243: error: in statement
# VUSE { SFT.956 }
D.17707_131 = node_online_map.bits[0];
mm/slab.c:2243: internal
--- Comment #1 from rask at sygehus dot dk 2007-07-06 20:50 ---
Created an attachment (id=13856)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13856&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32656
tor-layout.c:220
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC build triplet: x86_64-unknown
--- Comment #4 from rask at sygehus dot dk 2007-07-07 16:08 ---
In reply to comment #1:
If you're splitting a multiword subreg (such as %rbx:%rcx) after reload, then
the prologue/epilogue code has no way of knowing that all use of %rbx is later
optimized away. I don't know
--- Comment #5 from rask at sygehus dot dk 2007-07-07 17:26 ---
s/multiword subreg/multiword hard reg/g and s/comment #2/comment #3/g in
comment #4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32662
--- Comment #1 from rask at sygehus dot dk 2007-07-11 08:53 ---
I think (1) and (2) is just the register allocator being stupid. This sort of
thing can happen when the %rax at (1) was a different pseudo register than the
%rax at (2). The register allocator is supposed to be able to tie
--- Comment #4 from rask at sygehus dot dk 2007-07-11 20:45 ---
In reply to comment #2:
Reload is unable to use a register with a REG_DEAD note for an output reload.
Look at the functions find_reload_regs(), order_regs_for_reload() and
find_reg() and pay attention to how they use chain
--- Comment #1 from rask at sygehus dot dk 2007-07-13 15:34 ---
I don't see how R can become negative:
R=0;
while (...)
{
...
R=R*5+[unsigned value here];
...
}
What am I missing?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32757
--- Comment #3 from rask at sygehus dot dk 2007-07-13 15:40 ---
Well, if you declare R as unsigned, GCC will still optimize away "if (R<0)".
;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32757
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
Target Milestone: ---
This causes an ICE:
#include
extern "C" void __cxa_allocate_exception(std::size_t size);
int f(int x)
{
if (x > 27)
throw 19;
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
Target Milestone: ---
I need to enable -mlongcall for a PPC/VxWorks target. However, starting from
gcc 6, that leads to lots of warnings due to the "lon
++
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
Target Milestone: ---
The comment above the definition of __cpp_transactional_memory suggests that
201500 was meant to be used. Currently, gcc advertises support for whatever
transactional_memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86068
--- Comment #2 from Rasmus Villemoes ---
The page https://gcc.gnu.org/projects/cxx-status.html probably needs to be
updated to say __cpp_transactional_memory >= 201500.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86338
--- Comment #2 from Rasmus Villemoes ---
I believe and hope Rainer's fix r262195 also takes care of these.
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: larsch at belunktum dot dk
Target Milestone: ---
There seem to be a severe ~20% code size regression on AVR target (atmega328p)
in gcc 9.1.0.
I'm building https://github.com/gnea/grbl, which ne
: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: pdj at knaldgas dot dk
Target Milestone: ---
Host: x86_64
Target: x86_64
Build: x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64965
Rasmus Villemoes changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: pdj at knaldgas dot dk
Target Milestone: ---
In both C and Ada, bitfield coalescing does not work right, or at least not
optimal. Since the issue manifests itself in the same way in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91131
--- Comment #1 from Per Dalgas Jakobsen ---
Created attachment 46585
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46585&action=edit
MWE: Preprocessed C-file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91131
--- Comment #5 from Per Dalgas Jakobsen ---
(In reply to Richard Biener from comment #2)
> So your complaint is that
>
> struct Reg_T {
> unsigned int a : 3;
> unsigned int b : 1;
> unsigned int c : 4;
> } __attribute__((
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91131
--- Comment #6 from Per Dalgas Jakobsen ---
(In reply to Richard Biener from comment #3)
> note your use of packed might end up doing more than one store depending
> on the architecture.
If you mean that a packed structure beyond the data-width
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91131
--- Comment #9 from Per Dalgas Jakobsen ---
(In reply to Richard Biener from comment #8)
> Fixed on trunk sofar.
>
> Note the non-optimal code-gen probably was a side-effect of us making
> three volatile accesses out of one. On x86 I now see
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91131
--- Comment #11 from Per Dalgas Jakobsen ---
(In reply to Richard Biener from comment #10)
> (In reply to Per Dalgas Jakobsen from comment #9)
> > avr-gcc -O3 (and -Os, -O1, -O2):
> > sts 0x0064, r1 ; 0x800064
> > ldi r24, 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91131
--- Comment #12 from Per Dalgas Jakobsen ---
Created attachment 46591
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46591&action=edit
Added more combinations of bitfield sets.
Now includes all 8 combinations of zero/non-zero assignments t
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
Target Milestone: ---
Consider these examples:
#include
#include
const char *foo (const char *fmt, ...)
__attribute__((format(printf, 1, 2)));
int f1(const char *s, int x)
{
const
compiling xorg-x11 6.8.2
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: blocker
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: redeeman at metanurb dot dk
http://gcc.gnu
--- Comment #1 from redeeman at metanurb dot dk 2005-10-25 13:56 ---
Created an attachment (id=10054)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10054&action=view)
cc5F7DsV.out
this is the output thing it talks about in the error message
--
http://gcc.gnu.org/b
--- Comment #3 from redeeman at metanurb dot dk 2005-10-25 14:03 ---
bugs.gentoo.org is just a bugzilla - but i figure this is not a gentoo problem.
i guy told me to report it to gcc's bugzilla. so i did.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24521
--- Comment #5 from redeeman at metanurb dot dk 2005-10-25 14:40 ---
hmm ok.. do you think it could be because it is a 32bit chroot within a 64bit
install?
anyway, i will try a vanilla gcc 4.0.2, and get back to you later today or
tomorow perhaps (more likely)
--
http
RMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mbo at intec dot dk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24595
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at fischerpaulsen dot dk
Target Milestone: ---
Created attachment 40391
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40391&action=edit
Faulty code
The i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78891
Christian Paulsen changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVAL
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
Target Milestone: ---
Everything below applies to the case of unsigned operands; signed division is a
whole other matter.
When a is an odd constant, the expression x % a == 0 is equivalent to x
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: sgh at sgh dot dk
Target Milestone: ---
All IDE's does not understand GCC unless is "speaks" english. Disabling is
using the environment is not a solution because the environment for cmake+ninja
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79423
--- Comment #3 from Søren Holm ---
Yes - it sound much like what I want.
The diagnostics stuff in gcc7 seem a bit overkill when the real issue is just
the translation of "error" and "warning"
A commandline flag that forcesg gcc to call setenv("
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hjp at liab dot dk
This is possibly related to #54787, but with a different case.
After finding a bug in code compiled with avr-gcc, I created this test case, as
no warning was issued when I expected it. The following test
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: stefan at astylos dot dk
Target: cr16
Created attachment 32769
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32769&action=edit
Preprocessed source
When a cr16 crosscompiler builds gcc, the return s
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: simon at newtec dot dk
Target Milestone: ---
Created attachment 35584
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35584&action=edit
Quick test, just compile with g++
I'm
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: larsch at belunktum dot dk
Target Milestone: ---
gcc 4.5.3 through to 5.2.0 all warn about reaching end of non-void function on
this code:
struct foo { ~foo(); };
int f
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
Target Milestone: ---
int f(unsigned a, unsigned b)
{
if (!a || b >= a)
return 5;
return 2;
}
compiles to
f(unsigned int, unsigned
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
Target Milestone: ---
Using "a + b < a" is the standard (and well-defined) way of checking for
overflow when adding unsigned variables
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
(Not sure the "Component" is correct). gcc fails to optimize
if (foo & FLAG)
foo &= ~FLAG;
into simply uncondi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64567
--- Comment #2 from Rasmus Villemoes ---
(In reply to Andreas Schwab from comment #1)
> This transformation is incorrect if the lvalue may be pointing to a
> read-only object.
True. And one may also incur an extra cache penalty if the cache line
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
Host: x86_64
Target: x86_64
The linux kernel's library strncmp is this:
int strncmp(const char *cs, const char *ct, size_t count)
{
unsigned char c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64753
--- Comment #1 from Rasmus Villemoes ---
FWIW, I wrote a stupid script looking for the pattern
<(conditional) jump to abcd>
...
abcd:
Compiling a defconfig linux kernel with gcc 4.7 gives 201 instances, 5.0 gives
252. The second test/cm
y: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
While trying to come up with test cases for a bug in the static analyzer
sparse, I tried to see how gcc did in some corner cases. Turns out that using
__FILE__ in a file whose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64965
--- Comment #1 from Rasmus Villemoes ---
Created attachment 34693
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34693&action=edit
Make __FILE__ work for filenames containing newline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64965
Rasmus Villemoes changed:
What|Removed |Added
Severity|normal |minor
--- Comment #2 from Rasmus Vill
++
Assignee: unassigned at gcc dot gnu.org
Reporter: mnsc at dtu dot dk
++
Assignee: unassigned at gcc dot gnu.org
Reporter: mnsc at dtu dot dk
Created attachment 33516
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33516&action=edit
Minimal example
I get "internal compiler error: Segmentation fault" (no proper error message)
w
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
CC: rostedt at goodmis dot org
Target Milestone: ---
The motivation for this comes from the linux kernel's
include/trace/trace_events.h file (hence the cc Steven Rostedt
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
Target Milestone: ---
Target: x86/generic
In code such as
unsigned f(unsigned x, int n)
{
return x >> (n % 32);
}
I think gcc sho
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
Target Milestone: ---
Playing around with the __builtin_*_overflow checkers, I noticed that when the
third argument is pointer to _Bool one gets "error: argument 3 in call to
fun
--- Additional Comments From mki at maconomy dot dk 2005-07-15 16:52
---
Meetoo :-(
Note that the bug is on hppa2.0w-hp-hpux11.11 but not on i686-pc-linux-gnu. (And
on HP 3.4.3 works but 4.0.1 doesn't.)
--
What|Removed |
--- Additional Comments From mki at maconomy dot dk 2005-07-15 19:11
---
I'm using gas from binutils-2.16. But the ICE seems to appear before as is run
at all (If the cc1plus command succeeds it will be followed by
"/usr/local/binutils-2.16/bin/as -o trauscher.o trausche
--- Additional Comments From mki at maconomy dot dk 2005-07-27 16:30
---
Hi,
Dave, you mentioned that it "needs debugging on a system that can reproduce it".
Is there anything I can do to debug it? It seems like you know what to look
for... Something like building gcc with -
ind a 3.x.x solution...
--
Summary: internal compiler error: in c_expand_expr, at c-
common.c:4138
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo:
--- Additional Comments From mki at maconomy dot dk 2005-08-01 13:45
---
Forgot to mention:
The ICE seems to be platform specific. My testcase works on linux with 3.3.4,
3.4.3 and 4.0.1.
It thus (to me) seems slightly related to PR c++/21123... (But
--disable-checking makes no
ponent: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cr at silicide dot dk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42449
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49094
--- Comment #10 from Søren Holm 2011-07-30 12:10:57 UTC ---
Created attachment 24869
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24869
Another testcase that fails. Even with current 4.6
With "static" on line 33 the code generated is wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49094
Søren Holm changed:
What|Removed |Added
CC||sgh at sgh dot dk
--- Comment #11 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49094
--- Comment #12 from Søren Holm 2011-07-30 12:30:25 UTC ---
Oh... I just realized that the failing case does not fail because of the first
ldr-instruction. It fails becasue of something else. Maybe you guys have a
better eye for ARM-assembler to b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49094
--- Comment #13 from Søren Holm 2011-07-30 12:37:41 UTC ---
gcc 4.4.6 generates the following code with the "static" keyword
unsigned int aostk_font_strwidth(const struct aostk_font* font, const char*
str) {
0: e5d02004ldrbr2, [r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49923
Summary: __attirubte__((packed)) on ARM is sometimes dropped
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: una
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49923
--- Comment #1 from Søren Holm 2011-07-31 15:16:21 UTC ---
Created attachment 24878
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24878
Test that generates wrong aligned ldr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49094
--- Comment #15 from Søren Holm 2011-07-31 15:18:19 UTC ---
I have reported the bug as #49923
-fno-tree-sra does not help.
I have bisected it to commit trunk@164135
2010-09-10 Martin Jambor
PR tree-optimization/44972
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49923
--- Comment #2 from Søren Holm 2011-08-02 12:19:15 UTC ---
Martin, do you have an idea as to was is wrong ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49923
--- Comment #4 from Søren Holm 2011-08-02 13:26:25 UTC ---
Adding -fno-ipa-sra makes gcc behave correct. Can it be fixed for 4.6.2 ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49923
--- Comment #6 from Søren Holm 2011-08-03 21:00:06 UTC ---
As far as my isolated test-case goes the patch works. :D
I will report back after a test on the target tomorrow.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49923
--- Comment #7 from Søren Holm 2011-08-04 08:00:14 UTC ---
It works on the target too. From my perspective your patch fixes this issue.
Thank you very much Martin.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49923
--- Comment #10 from Søren Holm 2011-08-09 06:37:41 UTC ---
Sweet, but why is it not applied to gcc-4_6-branch ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49923
--- Comment #12 from Søren Holm 2011-08-09 07:37:30 UTC ---
Great. I asked because other bugfixes has been commited both places in a single
commit. :)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49923
--- Comment #15 from Søren Holm 2011-08-09 17:19:06 UTC ---
Sweet. Thanks Martin :)
nable_languages-all} \
--target=$target_alias --host=$build_alias --build=$build_alias
--
Summary: Wrong preprocessor called in build-i686-
cygwin/libiberty/configure
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Sev
: unassigned at gcc dot gnu dot org
ReportedBy: davh at davh dot dk
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34593
--- Comment #2 from davh at davh dot dk 2007-12-26 16:16 ---
Indeed... I need glasses, sorry for the bother,
--
davh at davh dot dk changed:
What|Removed |Added
leaq.LC1(%rip), %rdi
call[EMAIL PROTECTED]
.L3:
--
Summary: Labels are not handled correctly
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigne
--- Comment #1 from davh at davh dot dk 2008-01-01 08:33 ---
Even worse is this:
__asm__(
"someasm" :
:
"i" (&&a),
"i" (&&b));
a:
b:
.L2:
.LBB2:
.loc 1 25 0
#APP
/* My asm statements, which includes this in
ly due to large parameter
array
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnalle at ruc
--- Additional Comments From jacob at engelbrecht dot dk 2004-12-10 23:30
---
Then I do not understand why the second program is legal?
(After a bit of experimentation I found out that if the type name is used as
variable name then it can not be used as a typename again). I would
Think
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jacob at engelbrecht dot dk
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18930
--- Comment #9 from rask at sygehus dot dk 2006-12-11 20:24 ---
Created an attachment (id=12785)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12785&action=view)
Partial patch
Please try this patch. It removes the ICE, but the code may not run on 68000
and 68010 CPUs
bgcc2 powitf2 with ICE
in gen_reg_rtx
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at s
--- Comment #3 from rask at sygehus dot dk 2007-01-05 17:29 ---
Created an attachment (id=12861)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12861&action=view)
patch in testing to fix typo
The option -specs=ldblspecs is added by gcc/config/rs6000/t-ppccomm when
co
--- Comment #5 from rask at sygehus dot dk 2007-01-06 14:28 ---
The condition in t-ppccomm is written just like the example in the GNU Make
documentation ("Conditionals that Test Flags"), except for the missing
parentheses.
Indeed toplevel libgcc fixes this, revision 1205
--- Comment #7 from rask at sygehus dot dk 2007-01-07 14:07 ---
I tried to build several versions to find out which ones work:
GCC 4.0.3 works (dies later compiling newlib/libc/math/e_j0.c).
GCC 4.1.0 unknown (fails to compile rs6000.c).
GCC 4.1.1 works (dies later with bug 27075).
GCC
--- Comment #8 from rask at sygehus dot dk 2007-01-07 14:16 ---
Created an attachment (id=12869)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12869&action=view)
updated patch in testing
Here's a new patch as discussed. The GCC 4.2 branch now manages to build
libgcc
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jes at bodi-klinke dot dk
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20485
101 - 200 of 266 matches
Mail list logo
