http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54818
Bug #: 54818
Summary: error: type mismatch in binary expression
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priorit
++
Assignee: unassigned at gcc dot gnu.org
Reporter: t-gcc-bugzilla at snowelm dot com
Maybe similar to PR 57109, but the attached source for the PR was compiled
without problem in my environment, so I post this one as a new bug.
Due to bugzilla size limit, I had to compress the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57658
--- Comment #1 from Takaki Makino ---
It seems that the attachment file size was 1000.3KB and rejected by bugzilla.
Anyway please download preprocessed source from the URL above.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57658
--- Comment #3 from Takaki Makino ---
Created attachment 30336
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30336&action=edit
Reduced testcase
Hi Paolo,
Thank you for referring to the useful resource.
Using these tools I've got a reduced v
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: t-gcc-bugzilla at snowelm dot com
g++ 4.8.1 rejects the following code saying "B::base::f is inaccessible".
I believe the code is valid (and compiled without erro
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla-f5d8 at theblacksun dot eu
Created attachment 31327
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31327&action=edit
miscompilation testcase
The attached testcase miscompiles on sh4 target if build w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59343
--- Comment #2 from gcc-bugzilla-f5d8 at theblacksun dot eu ---
Created attachment 31330
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31330&action=edit
assembler output from -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59343
--- Comment #1 from gcc-bugzilla-f5d8 at theblacksun dot eu ---
Created attachment 31329
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31329&action=edit
assembler output from -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59343
--- Comment #3 from gcc-bugzilla-f5d8 at theblacksun dot eu ---
Created attachment 31349
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31349&action=edit
Second failing testcase. Triggers in -O1 and -O2 too
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59343
gcc-bugzilla-f5d8 at theblacksun dot eu changed:
What|Removed |Added
Target||sh4-unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59343
gcc-bugzilla-f5d8 at theblacksun dot eu changed:
What|Removed |Added
Known to work||4.7.3
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at mkarcher dot dialup.fu-berlin.de
Target Milestone: ---
As noted while filing a bug on rustc because rustc does not correctly implement
the Sparc64 ABI regarding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038
Bug #: 56038
Summary: declarations in xmmintrin.h conflict with mingw-w64
intrin.h in c++ mode
Classification: Unclassified
Product: gcc
Version: 4.8.0
Stat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79037
--- Comment #5 from Michael Karcher ---
The root issue now is that the ABI gcc implements on m68k is incompatible with
the Go runtime shipped with gcc.
The Go runtime uses the lowest two bits in the type information pointer as
flags (called PREC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79037
--- Comment #8 from Michael Karcher ---
The patch looks like it should work fine, I guess John Paul Adrian Glaubitz is
going to test it soon. But I wonder whether the determination of alignment is
in types.cc really needed, as user-specified alig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79037
--- Comment #10 from Michael Karcher ---
OK, I got it. I retract my last comment.
: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: tim+gcc-bugzilla at centricular dot com
Target Milestone: ---
gcc (Debian 6.3.0-4) 6.3.0 20170121
cpp (Debian 6.3.0-4) 6.3.0 20170121
Also happens with latest gcc7 snapshot on https://gcc.godbolt.org/
Linux 4.9.0-1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038
--- Comment #12 from Erik van Pienbroek ---
(In reply to tim.lebedkov from comment #11)
> Qt 5.2.1 cannot be build in 32 bit with mingw-w64 4.8.2 because of this bug.
> Why is it not fixed?
A fix for this issue was applied in the intrin.h of ming
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at mailhell dot seb7.de
While writing a DWARF parser/interpreter I hit what seems to be inconsistent
DWARF information.
The original source for my example originates from
"l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61595
--- Comment #1 from Sebastian Meyer ---
Created attachment 32999
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32999&action=edit
Example source, produced DWARF information and memory dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61595
--- Comment #4 from Sebastian Meyer ---
Richard: The typdef gets optimized away very quickly, so I needed to trick
around a bit. But the array won't use the typedef anyway, the produced DWARF is
equal to what was produced before (DWARF3 keeps it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61595
--- Comment #6 from Sebastian Meyer ---
Ah, okay, thank you for the clarification, Jakub.
So this is indeed RESOLVED INVALID, sorry.
I am still sure I saw the example I gave, but can't seem to find it now.
Chances are good though it wasn't GCC,
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at mkarcher dot dialup.fu-berlin.de
Target Milestone: ---
Created attachment 36537
--> https://gcc.gnu.org/bugzi
Severity: critical
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: erik-gcc-bugzilla at vanpienbroek dot nl
CC: jakub at gcc dot gnu.org, ktietz at gcc dot gnu.org
Target: i686-w64-mingw32
Recent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61805
gcc-bugzilla at ca dot sh13.net changed:
What|Removed |Added
CC||gcc-bugzilla at ca dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63783
Michael Karcher changed:
What|Removed |Added
CC||gcc-bugzilla at mkarcher dot
dialu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63783
--- Comment #5 from Michael Karcher ---
(In reply to Oleg Endo from comment #4)
> I'm not sure about this. The first hunk of your patch that removes the
> example in the top comment block should be valid, as far as I can see at the
> moment. Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63783
--- Comment #7 from Michael Karcher ---
(In reply to Oleg Endo from comment #6)
> > For the transformation to be valid, you would need a logical not instruction
> > instead of the bitwise not instruction that sets the desination register to
> > z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63783
--- Comment #8 from Michael Karcher ---
Actually, the whole issue got me curious - I will try prepare a different patch
along your suggestions and compare the compiler output. If I don't report back
today, I probably won't do that in time, so don
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63783
--- Comment #10 from Michael Karcher ---
Created attachment 33991
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33991&action=edit
Fix logical negation of registers, SImode only
In fact, it turns out, you were right. I implemented the solu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63783
--- Comment #11 from Michael Karcher ---
Putting things straight after trying it out:
(In reply to Michael Karcher from comment #7)
[...]
> and this gets (except SH2A with nott) transformed to (by
> define_insn_and_split "nott" in the machine de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63783
--- Comment #12 from Michael Karcher ---
Further digging into this showed that there actually is a pass that would merge
the two "tst r1,r1" instructions - the jump2 pass in cfgclenup.c.
The optimization is called "crossjumping" in gcc, also kno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63783
--- Comment #15 from Michael Karcher ---
I did not get around to test your proposed patch yet, but it seems like the new
"logical not" operation always compares only the low 32 bit against zero, even
if there is a 64 bit operand. If my analysis i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63783
--- Comment #18 from Michael Karcher ---
As I said, I did not try your patch, but just read the source. The assembly you
quoted convinces me that there is no problem in the code actually produced by
your patch, which is great. This is caused by t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63783
--- Comment #20 from Michael Karcher ---
(In reply to Oleg Endo from comment #19)
> > The or-then-SImode-compare optimization has an adverse effect on the test
> > coverage, it seems. In both cases, GET_MODE(src_reg) and GET_MODE(dst_reg)
> > are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63783
--- Comment #22 from Michael Karcher ---
OK, in that case I retract my objections and I think the patch is fine. I am
sorry for that mistake.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002
Michael Karcher changed:
What|Removed |Added
CC||gcc-bugzilla at mkarcher dot
dialu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002
--- Comment #16 from Michael Karcher ---
The bug seems to be quite similar to the infamous "sloth that was dropped on
the head as a baby"-bug Linus discovered (https://lkml.org/lkml/2014/7/24/584 ,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=619
IRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: t-gcc-bugzilla at snowelm dot com
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=34825
c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: list+gcc-bugzilla at meyering dot net
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26213
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at meta-dynamic dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26295
NOTE: Defaulting component because reported component no longer exists
When compile with gcc-3.4 -O1 -fgcse -c -o qemu-bug.o qemu-bug.c,
there will be the error:
[EMAIL PROTECTED]:~/src/qemu-bug$ gcc-3.4 -O1 -fgcse -c -o qemu-bug.o qemu-bug.c
qemu-bug.c: In function `main':
qemu-bug.c:2: error: in
When building gdb with -Werror, the compile fails due to what looks
like a spurious warning from using -Wuninitialized. I've reduced the
testcase down to a minimal one, hopefully preserving the original
cause of the warning.
Environment:
System: Linux puffer.diveadx.com 2.6.16-1.2069_FC4smp #1
If you use memcmp to compare strings, it does not stop reading when it
finds the terminating null byte of the shortest string, which can
trigger an attempt to read unallocated memory. I'd recommend
replacing instances of memcmp on strings with strncmp, which won't
attempt to read past the end of
When compiling a C++ program (for the AVR target) that defines interrupt
vectors using the externally_visible attribute, I get this ICE message:
avrlib/bits/atmega128_usart.cpp:20: internal compiler error: tree check:
expected tree that contains 'decl minimal' structure, have 'omp_atomic' in
eq_
Current mainline fails to bootstrap on IRIX 5.3:
configure: error: Pthreads are required to build libgomp
make[1]: *** [configure-target-libgomp] Error 1
Environment:
System: IRIX lyra 5.3 11091812 IP22 mips
host: mips-sgi-irix5.3
build: mips-sgi-irix5.3
target: mips-sgi-irix5.3
configured wi
P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27689
--- Comment #2 from gcc-bugzilla at contacts dot eelis dot net 2006-05-20
21:32 ---
But for what F and T would F match foo::bar ?
In looking for workarounds I found that the same problem occurs when using
partial specialization:
template struct S {};
template class T> struc
I was trying to install the amule-2.0.3-r4 package from source in my gentoo
linux.
The package is public so if it could be a package error it should be reported
on their web site, but it is not.
I send this bug directly to you gcc-team, without interesting the gentoo
forums, cause it is reproducib
A memory leak happens when std::ios::sync_with_stdio(false);
valgrind:
...
==13644==
==13644== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==13644== malloc/free: in use at exit: 122,880 bytes in 6 blocks.
==13644== malloc/free: 6 allocs, 0 frees, 122,880 bytes allocated.
==136
Bootstrapping current mainline with Ada included fails on Tru64 UNIX V5.1B
when linking gnatbind:
/vol/gccsrc/obj/gcc-4.2.0-20060606/5.1b-gcc/./prev-gcc/xgcc
-B/vol/gccsrc/obj/gcc-4.2.0-20060606/5.1b-gcc/./prev-gcc/
-B/vol/gcc/alpha-dec-osf5.1b/bin/ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings
-W
Bootstrapping mainline on Solaris 10/x86 (configured for
i686-pc-solaris2.10 to work around the still unfixed PR target/26146) fails
compiling several Ada files:
/vol/gccsrc/obj/gcc-4.2.0-20060606/10-gcc-gas-amd64/./gcc/xgcc
-B/vol/gccsrc/obj/gcc-4.2.0-20060606/10-gcc-gas-amd64/./gcc/
-B/vol/gcc/
Trying to bootstrap mainline on IRIX 6.5 with java included failed since
boehm-gc (which is required for libjava) isn't built:
In file included from /vol/gcc/src/gcc-dist/libjava/include/jvm.h:25,
from /vol/gcc/src/gcc-dist/libjava/include/java-interp.h:14,
from
Between 20050805 and 20060208, many libjava execution tests started to time
out on Tru64 UNIX (both V4.0F and V5.1B), as can be seen comparing the
following test results:
http://gcc.gnu.org/ml/gcc-testresults/2005-08/msg00708.html
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00899.html
While
Since at least 20060503, libjava fails to bootstrap on IRIX 6.5.28:
/vol/gccsrc/obj/gcc-4.2.0-20060616/6.5-gcc-java/./gcc/xgcc -shared-libgcc
-B/vol/gccsrc/obj/gcc-4.2.0-20060616/6.5-gcc-java/./gcc -nostdinc++
-L/vol/gccsrc/obj/gcc-4.2.0-20060616/6.5-gcc-java/mips-sgi-irix6.5/32/libstdc++-v3/src
An array of 64K labels triggers the error.
Environment:
System: FreeBSD FreeBSD.jphartmann.net 6.1-RELEASE FreeBSD 6.1-RELEASE
#1: Sat Jun 17 11:51:42 CEST 2006
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/KERNEL i386
host: i386-unknown-freebsd6.1
build: i386-unknown-freebsd6.1
Bootstrapping current mainline on Tru64 UNIX fails in stage1 as of 20060705:
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I.
-I/vol/gcc/src/gcc/
Bootstrapping current mainline as of 20060705 fails on Tru64 UNIX V5.1B
when trying to genererate the PCH file for extc++.h:
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/./gcc/xgcc -shared-libgcc
-B/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/./gcc -nostdinc++
-L/vol/gccsrc/obj/gcc-4.2.0-20
libgomp just doesn't configure any more on Tru64 UNIX V5.1B:
configure: error: Pthreads are required to build libgomp
This is due to the last configure.ac change:
2006-07-05 Eric Christopher <[EMAIL PROTECTED]>
* configure.ac: Depend addition of -pthread on host OS.
* configu
While investigating the root cause of PR libgcj/28189, I noticed that both
on the 4.1 branch and on mainline (where the libjava testsuite timeouts
occur) the boehm-gc test had started failing as well (which easily goes
unnoticed due to PR boehm-gc/11412): gctest fails like this:
Key creation fail
libstdc++ fails to bootstrap on Tru64 UNIX as of 20060710:
/vol/gccsrc/obj/gcc-4.2.0-20060710/4.0f-gcc/./gcc/xgcc -shared-libgcc
-B/vol/gccsrc/obj/gcc-4.2.0-20060710/4.0f-gcc/./gcc -nostdinc++
-L/vol/gccsrc/obj/gcc-4.2.0-20060710/4.0f-gcc/alpha-dec-osf4.0f/libstdc++-v3/src
-L/vol/gccsrc/o
-std=c89 doesn't warn about gcc's "?:" extension
Environment:
System: Linux rho 2.6.15-1-amd64-k8 #2 Tue Mar 7 06:53:26 UTC 2006 x86_64
GNU/Linux
Architecture: x86_64
host: x86_64-unknown-linux-gnu
build: x86_64-unknown-linux-gnu
target: x86_64-unknown-linux-gnu
configured with: /mirror
In the context of a function returning int, and rfp->signed is a
one-bit field,
return rfp->signed_flag ? 1 : 0;
yields -1. This is an optimization problem, seen with -O2 but not -O1.
Isolated to -ftree-vrp. Not seen in gcc-4.3 or earlier.
Environment:
System: Li
Example program works with option -O1, but not with -O2
Problem occurs with gcc 4.3.2 and 4.4.0, but not with 4.2.4
Environment:
System: Linux andiunx 2.6.27-11-generic #1 SMP Fri Dec 19 16:29:52 UTC 2008
i686 GNU/Linux
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i68
Compiling the following (nonsense but valid) code triggers an internal
compiler error.
Environment:
System: Linux thanatos 2.6.26-2-686-bigmem #1 SMP Thu Mar 26 02:03:34 UTC 2009
i686 GNU/Linux
How-To-Repeat:
Compile the following:
-- snip --
struct s {
NS='-O2' '-c' '-v' '-shared-libgcc' '-mtune=generic'
g++ -O2 -c -v g++-stall.cpp 20.30s user 0.01s system 99% cpu 20.328 total
--
Summary: it takes too much time to compile using -O2
Product: gcc
Version: 4.3.2
compile the attached code with the -std=c++0x flag.
Environment:
System: Linux x 2.6.26-2-686 #1 SMP Thu Mar 26 01:08:11 UTC 2009 i686 GNU/Linux
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ./configure --prefix=/home/x/gcc-4.4-20090616
--e
err_bad_typedef.c leads to a call to initialize_aggregate with
arg->elemnts==NULL. This sets ptr on line 46 of
libffi/src/prep_cif.c to NULL, which is then dereferenced on
line 48.
Environment:
System: Linux dps 2.6.30.1-nofb #3 SMP PREEMPT Tue Jul 7 13:26:53 B
A simple function to store a small struct ends up writing the struct to
memory twice unnecessarily (plus writing it for real the third time).
The function's args are passed in r0-r3 (with r1-r3 being the struct).
It compiles to a sequence containing the following loads and stores,
among others:
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41037
Explicit conversion from a numeric integer Type to Integer causes a crash of
gcc
when the type is defined with a Size representation clause.
The bug disappears if the representation clause is removed or
if the range begins with 0.
Environment:
System: Linux simone 2.6.12.051101 #1 Tue Nov 1 17:19
The G4 PowerPC processor does not support the (full) GPOPT instruction
set that can be activated with -mpowerpc-gpopt. The documentation is not
explicitly clear on which (current) processors support this instruction set -
or any of the other additional/extended/optional sets like those se
This gcc version always requires that system have at least one
floating value that is usable as `NAN' - in its own headers or
specified in build configuration. In this system with this compiler
it is not the case. Can not obtain `NAN' value at all. When trying
to compute it dynamically, the pr
hi -
The current gcc in the 4.1 branch (svn rev 107578) miscompiles the following
source with -O3 -fno-strict-aliasing:
---
// g++ -O3 -g -fno-strict-aliasing -o x x.cc
inline void* operator new(unsigned, void* __p) thr
Using an example from the GCC documentation doesn't work. I don't know if the
documentation is broken
or the compiler.
Environment:
System: FreeBSD inchoate.localdomain 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sat
Oct 8 10:25:52 CST 2005 root@:/usr/obj/usr/src/sys/INCHOATE i386
host: i386-portbld-fre
when trying to include file mmintrin.h in any file, compilation fails with
the following message:
mmintrin.h: In function '_mm_add_si64':
mmintrin.h:280: error: can't convert between vector values of different size
mmintrin.h: In function '_mm_sub_si64':
mmintrin.h:382: error: can't convert bet
Segmentation fault:
#gfortran4.0 -c wave.f90
wave.f90:80: internal compiler error: Segmentation fault
I believe this worked under gfortran 4.0.
Environment:
System: Linux FUME.WPI.EDU 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:00:54 EDT 2005
x86_64 x86_64 x86_64 GNU/Linux
Architecture: x86_64
host:
gcov incorrectly shows that a lone return statement inside a block
has executed when in fact it has not
Environment:
System: Linux mercury.acucorp.com 2.4.18-27.8.0smp #1 SMP Fri Mar 14 07:13:13
EST 2003 i686 athlon i386 GNU/Linux
Architecture: i686
host: i686-pc-linux-gnu
build
Flags that are passed to newly built gcc when compiling code for
target system during are determined by value of `CFLAGS_FOR_TARGET'
makefile variable as defined in top level `Makefile'. `CFLAGS' in
that `Makefile' are passed on for use with old compiler used to
bootstrap gcc.
Can not configure
A 'field offset' macro which has worked so far (up to gcc-3.4.3) now
causes an ICE.
Environment:
System: Linux suse2 2.4.19-64GB-SMP #1 SMP Mon Oct 21 18:48:05 UTC 2002 i686
unknown
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
con
While building the pwlib package on alpha, the following problem
occured:
http://buildd.debian.org/fetch.php?&pkg=pwlib&ver=1.8.7-1&arch=alpha&stamp=1131832002&file=log&as=raw
The build does involve a testrun after linking the library. This
testrun is compiling and executin
NOTE: Defaulting component because reported component no longer exists
When list of languages has java (--enable-languages=c,c++,ada,f77,objc,java)
passed then make bootstrap fails on java with the following error:
Making all in gcj
make[5]: Entering directory
`/root/gcc-build/x86_64-slackware-lin
When executing `make bootstrap', the following error occurs.
stage1/xgcc -Bstage1/ -B/usr/local/i686-pc-linux-gnu/bin/ -O2 -g
-fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition
Observing it at least on stage 1 compiler, and exactly the same way as
in 3.3.2.
If inline function, later called a functional, is passed a function
argument that is constant and inline, and said argument is called in
the functional body, and when inline expansions are on, compiler
expand inline
Some targets in `gcc/Makefile.in' built while `make bootstrap' specify
`-B$(build_tooldir)/bin/'. All of this is done when nothing from gcc
being built is installed in that directory yet. What is installed
there, if any, generally has nothing to do with gcc at all. It may
easily be files from o
FIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at seibutsu dot mailsnare dot net
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC targe
--- Comment #1 from gcc-bugzilla at seibutsu dot mailsnare dot net
2006-07-24 21:07 ---
Created an attachment (id=11931)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11931&action=view)
patch to reset uuU variable when a non-underscore is encountered
--
http://gcc.
System include file is broken as described in section.
fixincludes does not create any modification of it, let alone fixed as
described. Newly built gcc includes broken file when run. This may
break just any program built with gcc, and does break compiling
`toplev.c' with `stage1/xgcc' as desc
Stalin is a Scheme compiler that generates C code. Stalin is itself written in
C and can compile itself. I am preparing a new release of Stalin for Debian
Etch. This release compiles with earlier versions of gcc, such as gcc-4.0, but
not with gcc-4.1. It gives an ICE.
The preprocessed source is
I'm trying to compile svgalib (http://www.svgalib.org/) on my
FreeBSD/amd64 system.
Although the package uses assembler in a few places, this can be
disabled with the -DNO_ASSEMBLY flag. After the pre-processor
there is no assembler code in the trouble-some
Compilation of functions/subroutines with optional derived type arguments
gives segmentation fault.
a.F90: In function 'func':
a.F90:11: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for i
// BUG DEMO for gcc 4.1.2 (and 4.1.1) for 32-bit x86
//
// If operator delete() is over-ridden in a base class, then
// if the implementation of delete() stores into the storage used
// by the object, the store seems to be removed by the compiler
// (maybe because the compiler thinks stores to a d
Compilation of the attached code yields an ICE in certain cases.
Environment:
System: Linux chii 2.6.20 #3 SMP Sun Feb 11 23:52:47 EET 2007 x86_64 GNU/Linux
Architecture: x86_64
host: x86_64-pc-linux-gnu
build: x86_64-pc-linux-gnu
target: x86_64-pc-linux-gnu
configured with: ../src/conf
igned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31518
g++ parses the code correctly and calls the correct overloaded
increment operators, but in the wrong postfix order. The semantics of
postfix are to take the rvalue before invoking the method. Note this
is not related to multiple reference ordering between sequence points
as the object is only re
As of 20070730, all gfortran tests fail on alpha-dec-osf4.0f:
25729:./PR19754_2.exe: /sbin/loader: Error: Unresolved symbol in
/amnt/sequoia/export/vol/gcc/obj/alpha/gcc-4.3.0-20070730/4.0f-gcc/alpha-dec-osf4.0f/./libgfortran/.libs/libgfortran.so.3:
vsnprintf
25729:./PR19754_2.exe: /sbin/loader:
By using an integer variable as the size of an array to be
initialized on the stack, you can trick gcc into accepting
and trying to create a negatively-sized array. The assembly
it generates in such a case seems to indicate it really thinks
it has a negatively-sized array.
E
MED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33045
Version: 4.1.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net
GCC host triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067
--- Comment #2 from gcc-bugzilla at contacts dot eelis dot net 2007-08-14
17:19 ---
I know that, but that's irrelevant from a user interface perspective. The fact
remains that the error message is needlessly messy and would be far clearer and
less surprising to the user if it sai
101 - 200 of 481 matches
Mail list logo
