The libgfortran in trunk is slated to shortly have a version
bump from .1 to .2...
http://gcc.gnu.org/ml/fortran/2006-07/msg00128.html
I am wondering if any of the other shared libraries in gcc trunk
are slated to have major version bumps as well before gcc 4.2
branches? I ask because fink
Hello,
I've just noticed that gimplify_expr () function (from gimplify.c)
asserts when trying to gimplify a TARGET_MEM_REF.
TARGET_MEM_REF nodes are generated after the gimplification pass, this
is why gimple_expr (...) doesn't expect any TARGET_MEM_REF at all.
However,
Andrew Pinski wrote:
On Jul 14, 2006, at 11:01 PM, Roberto COSTA wrote:
Is it a bug... or am I trying to do something wrong?
Why are you trying to regimplify something which is in gimple?
I'm trying to generate new code, which happens to contain TARGET_MEM_REF.
To do that, I find more
Roberto COSTA wrote:
Andrew Pinski wrote:
On Jul 14, 2006, at 11:01 PM, Roberto COSTA wrote:
Is it a bug... or am I trying to do something wrong?
Why are you trying to regimplify something which is in gimple?
I'm trying to generate new code, which happens to contain TARGET_MEM_REF.
To do
Hi,
On Thu, 13 Jul 2006, Maurizio Vitale wrote:
my understanding of the x86_64 ABI is that the following structure should be
passed in registers:
Right.
struct data {
unsigned int x;
unsigned int y;
unsigned long z;
};
but when I compile:
#include stdio.h
Kaveh R. Ghazi [EMAIL PROTECTED] writes:
[...]
| I'd like to do for tree and rtx what I did for const char *,
| namely constify those tree/rtx functions that aren't supposed to
| modify their arguments. This would require introducing the
| const_tree and const_rtx typedefs
On 14 July 2006 18:22, Kaveh R. Ghazi wrote:
Now imagine if I change the type of __t to const_tree like so:
typedef const union tree_node *const_tree;
#define TREE_CHECK(T, CODE) __extension__ \
({ const_tree const __t = (T); \
if (TREE_CODE (__t) != (CODE)) \
tree_check_failed
Kaveh R. Ghazi [EMAIL PROTECTED] writes:
#define TREE_CHECK(T, CODE) __extension__ \
({ const_tree const __t = (T); \
How about
typeof(T) const __t = (T);
?
Ian
Gabriel Dos Reis [EMAIL PROTECTED] writes:
Jason Merrill [EMAIL PROTECTED] writes:
[...]
| | - I don't recall suggesting that
| | multiple types with the same name should be able to exist.
| then you have to consider that suggestion and come with an answer.
|
| I don't see why.
Tristan Wibberley [EMAIL PROTECTED] writes:
The types are defined in headers and are thus known
to exist - no visibility attributes will or should change that.
The question here is not whether the types exist, but which types are
the same as which other types.
I think that what you want is a
Jason Merrill [EMAIL PROTECTED] writes:
Benjamin Smedberg wrote:
Jason Merrill wrote:
Do you agree with implicitly giving template instantiations the
minimum visibility of the template and arguments unless explicitly
overridden?
This is not what I would naturally expect, coming from
Joe Buck [EMAIL PROTECTED] writes:
I wrote [for two classes S with visibility == hidden ]
| | We can have two distinct
| | classes named S, and no one can tell. Each bit of code will see one
| | definition of S.
Jason Merrill [EMAIL PROTECTED] writes:
| I think that Joe's point is
Jason Merrill [EMAIL PROTECTED] writes:
Gabriel Dos Reis wrote:
Jason Merrill [EMAIL PROTECTED] writes:
So, -concretely- what happens to a class S (e.g. associated type
info object
address, address of member functions, etc.) with external linkage,
defined in multiple translation units,
On Thu, Jul 13, 2006 at 03:41:29PM +0200, Gabriel Dos Reis wrote:
I'm not clear about you can't compare them.
Surely, I can take the address of typeid(S) and pass it around to
a function in another translation unit. I can do
typeinfo1-before(*typeinfo2), where typeinfo1 and
Joe Buck [EMAIL PROTECTED] writes:
On Thu, Jul 13, 2006 at 03:41:29PM +0200, Gabriel Dos Reis wrote:
I'm not clear about you can't compare them.
Surely, I can take the address of typeid(S) and pass it around to
a function in another translation unit. I can do
GCC,
We currently search both the relocated compilers prefix and the
originally configured prefix. Should a relocated compiler be searching
both directories?
Does anyone see a need to search *both* the configured prefix and the
relocated prefix? You can end up finding things you don't mean to
First of all, thank you for seeing the problem I was trying to
communicate.
Geoffrey Keating [EMAIL PROTECTED] writes:
| Joe Buck [EMAIL PROTECTED] writes:
|
| I wrote [for two classes S with visibility == hidden ]
| | | We can have two distinct
| | | classes named S, and no one can
Geoffrey Keating [EMAIL PROTECTED] writes:
| Joe Buck [EMAIL PROTECTED] writes:
|
| On Thu, Jul 13, 2006 at 03:41:29PM +0200, Gabriel Dos Reis wrote:
| I'm not clear about you can't compare them.
|
| Surely, I can take the address of typeid(S) and pass it around to
| a function
Geoffrey Keating [EMAIL PROTECTED] writes:
| Jason Merrill [EMAIL PROTECTED] writes:
|
| Gabriel Dos Reis wrote:
| Jason Merrill [EMAIL PROTECTED] writes:
| So, -concretely- what happens to a class S (e.g. associated type
| info object
| address, address of member functions, etc.) with
On 14/07/2006, at 3:01 PM, Gabriel Dos Reis wrote:
First of all, thank you for seeing the problem I was trying to
communicate.
Geoffrey Keating [EMAIL PROTECTED] writes:
| Joe Buck [EMAIL PROTECTED] writes:
|
| I wrote [for two classes S with visibility == hidden ]
| | | We can have two
On Jul 14, 2006, at 3:01 PM, Gabriel Dos Reis wrote:
That would mirror how C++ handles classes in unnamed namspaces. In
other words, the visibility would have to be part of the mangled name.
Can't do that and preserve the abi, also, there is no concept in gcc
currently to so name it, and
Geoffrey Keating [EMAIL PROTECTED] writes:
[...]
| | I don't think you can say 'no piece of code knows about both of
| them'.
| | What you can say is that these two classes are both named S but
| | they're different, just as if they were in different namespaces.
|
| That would mirror how
Mike Stump [EMAIL PROTECTED] writes:
[...]
| All in all, we should just agree to not worry about non-merged
| typeinfo name, or remove support for it.
If we remove support for it, then that indeed simplifies the issue.
-- Gaby
On Sat, Jul 15, 2006 at 12:19:40AM +0200, Gabriel Dos Reis wrote:
On platfoms where __GXX_MERGED_TYPEINFO_NAMES is not defined, before()
is defined in terms of the mangled names of the types. I'm unable to
find the mangled names are different.
Which is why we should just say that it is
Joe Buck [EMAIL PROTECTED] writes:
| On Sat, Jul 15, 2006 at 12:19:40AM +0200, Gabriel Dos Reis wrote:
| On platfoms where __GXX_MERGED_TYPEINFO_NAMES is not defined, before()
| is defined in terms of the mangled names of the types. I'm unable to
| find the mangled names are different.
|
|
On Jul 14, 2006, at 3:50 PM, Gabriel Dos Reis wrote:
I seem to remember a PR posted by Adobe people kind of related to
this, but maybe I'm remembering wrong. I have to dig up bugzilla.
If it is a bug that describes how matching doesn't work across dylibs
on older darwin systems (pre-tiger),
On Jul 14, 2006, at 4:03 PM, Gabriel Dos Reis wrote:
What that concretely means is that it alienates, for example, codes
based on Factory desigbn pattern using typeinfo objects.
I'd love some input from the MS VC++ programming crowd on this
issue. I don't see how they get past this issue.
On Sat, Jul 15, 2006 at 01:03:46AM +0200, Gabriel Dos Reis wrote:
Joe Buck [EMAIL PROTECTED] writes:
| On Sat, Jul 15, 2006 at 12:19:40AM +0200, Gabriel Dos Reis wrote:
| On platfoms where __GXX_MERGED_TYPEINFO_NAMES is not defined, before()
| is defined in terms of the mangled names of
Joe Buck [EMAIL PROTECTED] writes:
| On Sat, Jul 15, 2006 at 01:03:46AM +0200, Gabriel Dos Reis wrote:
| Joe Buck [EMAIL PROTECTED] writes:
|
| | On Sat, Jul 15, 2006 at 12:19:40AM +0200, Gabriel Dos Reis wrote:
| | On platfoms where __GXX_MERGED_TYPEINFO_NAMES is not defined, before()
| |
Snapshot gcc-4.1-20060714 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060714/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Mike Stump [EMAIL PROTECTED] writes:
| On Jul 14, 2006, at 4:03 PM, Gabriel Dos Reis wrote:
| What that concretely means is that it alienates, for example, codes
| based on Factory desigbn pattern using typeinfo objects.
|
| I'd love some input from the MS VC++ programming crowd on this
hi,
Is it possible to use the register ebp in the input/output register list in
gcc's inline assembly (for the x86 platform)? If so, how? If not, why not? I
would like to use ebp just like the other general purpose registers, e.g.
triggering a software interrupt 0x80 with value in eax:
On Jul 14, 2006, at 4:23 PM, [EMAIL PROTECTED] wrote:
Is it possible to use the register ebp in the input/output register
list
Wrong list. Also, for trivial questions like this, ask the compiler,
it will tell you.
Has anyone tried building python 2.4.3 using gcc trunk? The current gcc 4.2
seems to introduce a new regression in the Python testsuite...
test_builtin
test test_builtin failed -- Traceback (most recent call last):
File /Users/howarth/Python-2.4.3/Lib/test/test_builtin.py, line 233, in
I should have added that the gcc and python was built on MacOS X 10.4.
Jack
On Wed, 2006-07-12 at 17:57, Ian Lance Taylor wrote:
Personally, I think we should support operator[] for vectors.
Indeed, that was one of the most popular choices when I first brought
this topic up. I contributed mips vector support in August 2004, and in
the multiple threads that patch
How about
typeof(T) const __t = (T);
?
Ian
Oops, I didn't realize that using typeof preserves const-ness and
doesn't evaluate side-effects in T. After some quick testing it
turns out typeof is exactly what I needed. I'm regtesting some
patches now.
Thanks!
Diego Novillo wrote:
That's relevant at the language
syntactic/semantic level of validing such things as parameter lists, but to
GIMPLE two types are compatible if and only if they would produce the
identical RTL. So two integer types are compatible if they have the same
mode, precision, and
Jason Merrill wrote:
It seems that you have a different mental model of type visibility.
I've gotten a little lost in this thread. Is there a clear proposal for
the semantics that we're leaning towards at this point?
One meta-note is that we're not the first people to consider this. I
FWIW, I agree. However, I do not agree that two types are compatible
iff they would produce identical RTL. GIMPLE should still know that
int and long are distinct types (even if both 32 bits) since that
permits alias analysis to do a better job.
Sure, but that's not what we currently use
Richard Kenner wrote:
FWIW, I agree. However, I do not agree that two types are compatible
iff they would produce identical RTL. GIMPLE should still know that
int and long are distinct types (even if both 32 bits) since that
permits alias analysis to do a better job.
Sure, but that's not
In RTL, sure. In GIMPLE, I don't think so, as if you do that you lose
the type information about the result. But, I'm not a GIMPLE expert;
maybe there's some magic way of handling this.
The type of the result is always the type of the LHS. Nothing would
be changing that. And if you take
Richard Kenner wrote:
In RTL, sure. In GIMPLE, I don't think so, as if you do that you lose
the type information about the result. But, I'm not a GIMPLE expert;
maybe there's some magic way of handling this.
The type of the result is always the type of the LHS.
OK. But, GIMPLE is also
OK. But, GIMPLE is also supposed to be type-safe, so I wouldn't think
that int = long would be well-formed gimple.
I thought that type safe meant *compatible* types ...
On Jul 15, 2006, at 1:12 PM, Mark Mitchell wrote:
OK. But, GIMPLE is also supposed to be type-safe, so I wouldn't think
that int = long would be well-formed gimple.
Right now it is for 32bit targets because of
tree_ssa_useless_type_conversion_1's:
/* If both the inner and outer types
OK. But, GIMPLE is also supposed to be type-safe, so I wouldn't think
that int = long would be well-formed gimple.
... or we *could* define it that way.
My point is just that whatever type compatibility might mean at the
GIMPLE level, it should just be a function of whether the types will
--- 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
--- 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 #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 do
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
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 *, a
--- 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.
--
--- 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=path-where-libgcc_s.so-is ldd -r -v .../libstdc++-IFX.so
and you will see
--- 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=path-where-libgcc_s.so-is ldd
--- 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=gccview=revrev=115436
Log:
PR c++/28343
* decl.c (cp_finish_decl):
--- 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=gccview=revrev=115437
Log:
PR c++/28343
* decl.c (cp_finish_decl):
--- 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=gccview=revrev=115438
Log:
PR c++/28343
* decl.c (cp_finish_decl):
--- 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
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
--- 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=11888action=view)
Demonstrates an internal compiler error
Compile with:
gcc -o jscpucfg.o -c -Wall -Wno-format -DGCC_OPT_BUG -g
--- 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
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 #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=11889action=view)
Source for test case
This tarball contains a compiled version of the 'compiled by IBM' part of the
problem, as
--- 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
--- 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 #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 #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 #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
--- 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 #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 preprocessor.
--
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
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++
--- 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
--- 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)
--- 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
--- 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 #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 #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=gccview=revrev=115451
Log:
2006-07-14 Eliot Dresselhaus [EMAIL PROTECTED]
PR
--- 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 #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 #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
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
--- 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
--- 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
--- 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 #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 #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
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:
I have compiled the following code under gcc 3.4.6, 4.0.2, and 4.1.1:
=
#include iostream
class Foo {
public:
templatetypename T
void operator()(const T fcn) {
std::cout calling fcn()... std::endl;
fcn();
}
};
Consider the following testcase - a variant from
http://gcc.gnu.org/ml/gcc-help/2006-07/msg00177.html :
=
#include stdio.h
volatile char s[256][3];
int main()
{
int i, j=0;
for (i = 0; i 256; i++)
if (i = 128 i 256)
--- 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
--- 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
--
--- 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
--
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',
--
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
--- 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
--
--- 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
--- 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 #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
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
1 - 100 of 105 matches
Mail list logo
