--- Comment #7 from kkojima at gcc dot gnu dot org 2006-07-15 06:59 ---
Subject: Bug 28161
Author: kkojima
Date: Sat Jul 15 06:58:57 2006
New Revision: 115464
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115464
Log:
PR middle-end/28160
* stor-layout.c (place_fi
--- Comment #6 from kkojima at gcc dot gnu dot org 2006-07-15 06:59 ---
Subject: Bug 28160
Author: kkojima
Date: Sat Jul 15 06:58:57 2006
New Revision: 115464
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115464
Log:
PR middle-end/28160
* stor-layout.c (place_fi
--- Comment #5 from sabre at nondot dot org 2006-07-15 05:26 ---
Okay, I don't care who does or doesn't do it. :) It doesn't get diagnosed in
-E mode, though it's in clear violation of C99 6.10.3.2p2.
-Chris
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28388
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-07-15 05:25 ---
(In reply to comment #3)
> Right, but that is presumably the parser, not the preprocessor doing it... so
> it is a bug in the preprocessor.
Nope, that is the preprocessor doing it, you will notice the column field w
--- Comment #3 from sabre at nondot dot org 2006-07-15 05:23 ---
> Also without -E, we do warn about the second one:
> t.c:2:7: warning: unknown escape sequence '\`'
Right, but that is presumably the parser, not the preprocessor doing it... so
it is a bug in the preprocessor.
-Chris
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-15 05:21 ---
Also without -E, we do warn about the second one:
t.c:2:7: warning: unknown escape sequence '\`'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28388
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-15 05:21 ---
Well it is even worse than that, with the first one, we go into an infinite
loop when you don't use -E.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
GCC warns for:
#define A(b) #b
A(\ \\)
but not for:
#define A(b) #b
A(\`\\)
or seemingly any other character but space. While "\ " is not a valid escape
in a string, neither is \` or \Z. Either all or none should be warned about.
Further, the string should not be chopped into the really illeg
--- Comment #5 from unmesh dot churi at roguewave dot com 2006-07-15 00:50
---
Reply to Comment #4:
I do not have gcc 4.x handy to test the behavior, but reading the description
of the problem, the workaround mentioned looks good. Thanks.
--
unmesh dot churi at roguewave dot com cha
--- Comment #1 from sje at cup dot hp dot com 2006-07-14 22:53 ---
Proposed patch at http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00651.html
--
sje at cup dot hp dot com changed:
What|Removed |Added
-
--- Comment #2 from christophe dot jaillet at wanadoo dot fr 2006-07-14
21:11 ---
I tried to compile it on my cygwin box and had a strange (and certainly
unrelated) behaviour :
gcc -O3 test.c -S
Version 3.4.4 (must be the latest version available on cygwin :()
Description : the case 1
--- Comment #1 from patchapp at dberlin dot org 2006-07-14 20:35 ---
Subject: Bug number PR c++/28387
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00648.html
--
http://gcc.gnu.org/bugzil
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28387
Mainline's C++ frontend ICEs on the following code:
===
enum __attribute__((unused)) E;
===
bug.cc:1: error: use of enum 'E' without previous declaration
bug.cc:1: internal compiler error: tree check: expected class 'type', h
--- Comment #2 from patchapp at dberlin dot org 2006-07-14 20:30 ---
Subject: Bug number PR c++/28249
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00647.html
--
http://gcc.gnu.org/bugzil
--- Comment #2 from patchapp at dberlin dot org 2006-07-14 20:25 ---
Subject: Bug number PR c++/28250
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00646.html
--
http://gcc.gnu.org/bugzil
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-07-14 20:10
---
Confirmed.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Status|UN
Consider the following testcase - a variant from
http://gcc.gnu.org/ml/gcc-help/2006-07/msg00177.html :
=
#include
volatile char s[256][3];
int main()
{
int i, j=0;
for (i = 0; i < 256; i++)
if (i >= 128 && i < 256)
I have compiled the following code under gcc 3.4.6, 4.0.2, and 4.1.1:
=
#include
class Foo {
public:
template
void operator()(const T& fcn) {
std::cout << "calling fcn()..." << std::endl;
fcn();
}
};
void bar()
The "program"
save /rbuf_char/
end
produces:
0x080b503c in translate_common (common=0xa5005c0, var_list=Variable "var_list"
is not available.
)
at ../../trunk/gcc/fortran/trans-common.c:965
965 if (common_segment->offset != 0)
I propose to fix this directly with
Index: gc
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-07-14 19:34
---
Thansk for your report.
The bug is already known, though.
*** This bug has been marked as a duplicate of 27508 ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-07-14 19:34
---
*** Bug 28383 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from uweigand at gcc dot gnu dot org 2006-07-14 19:27
---
Yes, looks like this is long fixed. Closing bug now.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dje at gcc dot gnu dot org 2006-07-14 19:21 ---
rs6000_legitimate_offset_address_p() accepts constant offsets:
case V4HImode:
case V2SImode:
case V1DImode:
case V2SFmode:
/* SPE vector modes. */
return SPE_CONST_OFFSET_OK (offset);
It ac
--- Comment #3 from dje at gcc dot gnu dot org 2006-07-14 19:11 ---
This is because the E500 DOUBLE support wasn't prepared for complex doubles.
Index: rs6000.c
===
--- rs6000.c(revision 115431)
+++ rs6000.c(working
Hi, my first bug report here.
The code crashes gcc 4.1.1 but 3.4.4 does what it's supposed to and gives nice
error message. Anyways, here's the file gcc suggested me to send, i hope it
helps :)
// /usr/libexec/gcc/i386-pc-linux-gnu/4.1.1/cc1plus -quiet -D_GNU_SOURCE
crash.cpp -quiet -dumpbase cr
--- Comment #9 from green at redhat dot com 2006-07-14 18:35 ---
I ran into another instance of needing this in the jakarta-commons-io
testsuite.
It's been two years since the performance arguement against this change was
made. A lot of code has changed since then. Is it still a vali
--- Comment #18 from dje at gcc dot gnu dot org 2006-07-14 17:47 ---
Remove 4.2 regression designation.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from sje at cup dot hp dot com 2006-07-14 17:44 ---
Proposed patch at http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00642.html
--
sje at cup dot hp dot com changed:
What|Removed |Added
-
--- Comment #17 from dje at gcc dot gnu dot org 2006-07-14 17:44 ---
Subject: Bug 27287
Author: dje
Date: Fri Jul 14 17:44:27 2006
New Revision: 115451
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115451
Log:
2006-07-14 Eliot Dresselhaus <[EMAIL PROTECTED]>
PR targe
--- Comment #16 from edmar at freescale dot com 2006-07-14 17:19 ---
With the *correct* patch applied my regression tests are back to "normal", and
no sign of new issues.
Sorry for the previous confusion...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
--- Comment #9 from steven at gcc dot gnu dot org 2006-07-14 17:02 ---
The patch identified in comment #8 can't have caused the CSE problem, but it
probably exposed a latent bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27616
--- Comment #2 from steven at gcc dot gnu dot org 2006-07-14 16:59 ---
Enhancement request for compatibility with XLF. Not a high-priority
enhancement, but probably not very difficult to implement for a hobbyist.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from kargl at gcc dot gnu dot org 2006-07-14 15:01 ---
AFAIK, there isn't a option to do what you want. However,
this works. It is even standard conforming so it's
future proof whnen you move to another compiler.
program gfcbug37
external second
a = second (1.0)
p
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-14 14:40 ---
Trying updating binutils. The internal error is from binutils and not GCC so
closing as invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
The config command is:
configure --prefix=/home/phoenix411 --with-libiconv-prefix=/usr/local
--disable-multilib
then try to build with make bootstrap
The last couple of lines of output are:
/home/dsimmond/gcc/obj411/./gcc/xgcc -shared-libgcc
-B/home/dsimmond/gcc/obj411/./gcc -nostdinc++
-L/home/ds
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-07-14 14:08
---
> Ok, the compile is done. In gcc/Makefile.in, I changed
> -DLOCAL_INCLUDE_DIR=\"$(local_includedir)\" \
> to
> -ULOCAL_INCLUDE_DIR \
> so that /usr/local/include is NOT searched by default by the preproce
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-07-14 14:03
---
I think I broke this with my patch for PR 26151. :-(
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #35 from davidf at sjsoft dot com 2006-07-14 14:02 ---
This is also an issue with PyLucene under mod_python (in Apache).
PyLucene compiles Lucene with gcj and then wraps the interface to be callable
from Python. In order to do this it currently needs to create any Python
thre
--- Comment #5 from marek dot rouchal at infineon dot com 2006-07-14 14:01
---
Ok, the compile is done. In gcc/Makefile.in, I changed
-DLOCAL_INCLUDE_DIR=\"$(local_includedir)\" \
to
-ULOCAL_INCLUDE_DIR \
so that /usr/local/include is NOT searched by default by the preprocessor.
--- Comment #13 from falk at debian dot org 2006-07-14 12:26 ---
*** Bug 28379 has been marked as a duplicate of this bug. ***
--
falk at debian dot org changed:
What|Removed |Added
--
--- Comment #2 from falk at debian dot org 2006-07-14 12:26 ---
This is a duplicate of PR 26881.
*** This bug has been marked as a duplicate of 26881 ***
--
falk at debian dot org changed:
What|Removed |Added
-
--- Comment #2 from bim2006 at basistech dot com 2006-07-14 11:58 ---
In the real code where I encountered this originally, the ICE was reported on
the class that tried to implement the nested interface. When I boiled down the
test case to what I've posted, the ICE moved to the construct
--- Comment #1 from bim2006 at basistech dot com 2006-07-14 11:48 ---
Created an attachment (id=11889)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11889&action=view)
Source for test case
This tarball contains a compiled version of the 'compiled by IBM' part of the
problem, as we
A class compiled with the IBM Java 1.4.2 JDK defines a nested interface.
I use gcj 4.1.1 to compile the using class and the jar containing the class
containing the nested interface, and I receive, in return, a segv inside the
compiler.
I will post the complete repro materials.
make[1]: Leaving
--- Comment #4 from marek dot rouchal at infineon dot com 2006-07-14 11:03
---
I think I have found the root cause - there is indeed a
/usr/local/include/assert.h on my system. However, I was not aware that
/usr/local/include is being searched by default! So I will recompile
(bootstrap)
--- Comment #1 from stephan at s11n dot net 2006-07-14 11:01 ---
Created an attachment (id=11888)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11888&action=view)
Demonstrates an internal compiler error
Compile with:
gcc -o jscpucfg.o -c -Wall -Wno-format -DGCC_OPT_BUG -g -DXP_UN
Hi!
With gcc 4.1.0 and 4.1.1 on GNU/Linux platforms i can reliably reproduce an
internal compiler error. Unfortunately, there does not seem to be a way to
attach a file to this bug report, so i will instead post a URL:
http://s11n.net/tmp/jscpucfg.c
The command line is:
gcc -o jscpucfg.o -c -Wa
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-07-14 09:55
---
Fixed on mainline, 4.1 branch, and 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-07-14 09:53
---
Subject: Bug 28343
Author: reichelt
Date: Fri Jul 14 09:53:14 2006
New Revision: 115438
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115438
Log:
PR c++/28343
* decl.c (cp_finish_decl): Ch
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-07-14 09:49
---
Subject: Bug 28343
Author: reichelt
Date: Fri Jul 14 09:49:03 2006
New Revision: 115437
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115437
Log:
PR c++/28343
* decl.c (cp_finish_decl): Ch
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-07-14 09:43
---
Subject: Bug 28343
Author: reichelt
Date: Fri Jul 14 09:43:23 2006
New Revision: 115436
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115436
Log:
PR c++/28343
* decl.c (cp_finish_decl): Ch
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-07-14 09:14
---
> The test case is the build of gcc 4.0.3 on Solaris 8, including the
> libstdc++.so build.
This is known to work, e.g. http://gcc.gnu.org/gcc-4.0/buildstat.html
> env LD_LIBRARY_PATH= ldd -r -v .../libstdc++-IF
--- Comment #2 from marek dot rouchal at infineon dot com 2006-07-14 09:08
---
The test case is the build of gcc 4.0.3 on Solaris 8, including the
libstdc++.so build. When done, run
env LD_LIBRARY_PATH= ldd -r -v .../libstdc++-IFX.so
and you will see __eprintf unresolved.
I will try
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-07-14 08:55 ---
g++ links against libsupc++.a and the required static parts of libgcc_s.
Otherwise, a testcase would be nice because it is hard to see what exactly you
are doing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
Hi,
gfortran has the nasty behavior to fail on completely legal code
that uses subroutines or functions with whose name equals an extension.
g77 had flags to "hide" extensions, but there is no (no documented?)
way to do this with gfortran.
Example:
program gfcbug37
a = second (1.0)
print *,
These are two related problems. The most obvious one is that when building
libstdc++.so (don't mind the renaming, I want to isolate our gcc installation
from other tools that have their own libstdc++.so and set LD_LIBRARY_PATH,
because they are too stupid to use -rpath in their software) and I run
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-07-14 08:20 ---
(In reply to comment #3)
> This simplified test case ICEs already at -O:
>
> 00.expand already contains the unfolded leu. I suppose this is not valid RTL?
I think this is a case where we unroll the loop but don't d
--- Comment #3 from falk at debian dot org 2006-07-14 08:08 ---
This simplified test case ICEs already at -O:
static const long unsigned sizes[] = { 4, 8 };
static long unsigned maxSize(const long unsigned *v) {
unsigned long max = 0;
unsigned long i = 0;
for (;
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-14 07:58 ---
(In reply to comment #1)
> Note a related testcase is:
I have a patch to fix that related testcase and also fix some other issues
related to BIT_FIELD_EXPR expansion with vec_extract (and why vec_set is still
unused
61 matches
Mail list logo
