On Thu, Apr 27, 2006 at 05:16:10PM -0700, Joe Buck wrote:
On Thu, Apr 27, 2006 at 07:58:29PM -0400, Zack Weinberg wrote:
[ Unicode, UTF-{8,16}, BOMs, etc ]
It would also be good to take advantage of the fact that 95+% of C
source files start with /*, //, #i, or #d to distinguish
ASCII from
Hi all,
I'am tring to understand how g++ generate vtable for c++ on ia64. Here
is what I got in the CONSTRUCTOR_ELTS in a constructor node: (with g++ 3.3.2
fe)
=== source code ===
Class A
{
Public:
Virtual void f(){}
Virtual void g(){}
};
=== result ===
VAL: 0
SYMOFF: _ZTI1A(0x1901)+0(0x0)
On 27 April 2006 20:02, Mike Stump wrote:
On Apr 26, 2006, at 6:26 PM, Jack Howarth wrote:
readelf -d foo.so | grep TEXTREL
Does anyone know if some mechanism like this is possible for Darwin
shared libraries?
A man page is a terrible thing to waste:
Yes, but it's an even more
Hi
We have built h8300-elf toolchain based on gcc-4.1 (released). This
toolchain is based on following sources,
Binutils-2.16.92
Gcc-4.1-20060407
Newlib-1.14.0
Also we have built, GDB for h8300-elf using gdb-6.4.50.20060425
We have found following problems for all varients of h8 target,
1.
On Sat, 8 Apr 2006, Gerald Pfeifer wrote:
ftp://ftp.club-internet.fr/pub/gcc/ - severly out of date (3.3 is latest)
ftpmaster, I just confirmed this. Would you mind having a look and
letting us know how to proceed?
If this was this a technical glitch, and you plan to restart
mirroring
Hi all.
When compiling simple example (even c file with no code in it) with
dlx-elf-gcc -c -gdwarf-2 foo.c
I get the following error message:
internal compiler error: in assemble_integer, at varasm.c:2148
I've defined debugging support in the following way:
#define DBX_DEBUGGING_INFO
Dear List,
Dave Korn wrote
Well, at least the front page of gcc.gnu.org is now self-contradictory:
Previous release series: GCC 3.4.5 (released 2005-11-30)
Branch status: GCC 3.4.6 is the last release from the 3.4 series; the
branch has been closed after the release.
Not unless
On Apr 27, 2006, at 7:05 PM, Qiuker wrote:
Is there much difference from different PIC implement?
They all do exactly the same thing, allow code to be run at different
addresses, so they are all identical, or, yeah, they can be totally
different from just doing normal codegen and saving
On 28 April 2006 17:45, Bernard Leak wrote:
Dear List,
Dave Korn wrote
Well, at least the front page of gcc.gnu.org is now self-contradictory:
Previous release series: GCC 3.4.5 (released 2005-11-30)
Branch status: GCC 3.4.6 is the last release from the 3.4 series; the
branch
On Apr 28, 2006, at 3:18 AM, Dave Korn wrote:
Yes, but it's an even more terrible thing to wrap:
Welcome to format=flowed. :-( Apparently some companies think that
everyone uses an intelligent mail reader. I believe that if you read
it with just the right software, you'd see it as
It is my pleasure to announce that the steering committee has
appointed Richard Guenther libgcc-math maintainer.
Please adjust the MAINTAINERS file accordingly, Richard, and
Happy Hacking!
Gerald
Hello,
Consider the following test case:
struct A { bool g(int*, int*) __attribute__((nonnull (2))); };
bool A::g(int* a, int* b) {
if (a)
return 0;
return this;
}
G++ produces the following code for this snippet:
;; Function bool A::g(int*, int*) (_ZN1A1gEPiS0_)
bool A::g(int*,
Steven Bosscher wrote:
The documentation of the nonnull attribute says:
`nonnull (ARG-INDEX, ...)'
The `nonnull' attribute specifies that some function parameters
should be non-null pointers. For instance, the declaration:
extern void *
my_memcpy (void
Steven Bosscher wrote:
That is why I was looking at this. We have http://gcc.gnu.org/PR27336,
and part of the fix could be to make the 'this' pointer always
non-NULL. So far I haven't found anyone who can think of a situation
where 'this' can be NULL...
It can't be NULL. (There are ways to
DJ Delorie wrote:
Another one like libssp.
In libstdc++-v3's configure.ac, we see this:
# This depends on GLIBCXX CHECK_LINKER_FEATURES, but without it assumes no.
GLIBCXX_ENABLE_SYMVERS([yes])
The comment lies. If we haven't yet checked the linker features, it
will check them, and
The SC would like to ensure that before we accept any major
contribution, like a new runtime library or back end we have a
maintainer lined up for that component. The purpose of this policy is
to avoid taking code for which, for whatever reason, we cannot find an
available maintainer, or which
The key problem is that we have two ways
And then he lists *three* ;-)
* Hard-coded information about the target
I seem to recall a long time ago, talk of a global target capabilities
database. It proved too unwieldy to implement. However, a toplevel
configury snippet (aka config.gcc)
Snapshot gcc-4.1-20060428 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060428/
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
Right, I understand. Assuming that they exist at this point, you
could theoretically pass enough options to make it work -- although,
as you say, it's hard to know what those options ought to be. If
everything is set up right, it's -I options (for libc headers), -L
options (for libc and
DJ Delorie wrote:
Right, I understand. Assuming that they exist at this point, you
could theoretically pass enough options to make it work -- although,
as you say, it's hard to know what those options ought to be. If
everything is set up right, it's -I options (for libc headers), -L
options
Well, that sounds like an autoconf bug. If it refuses to work when
presented with a pile of compiler options, that just sounds bad.
No, I think it's our bug - we do this:
GCC_NO_EXECUTABLES
GLIBCXX_ENABLE_SYMVERS([yes])
You can't logically expect that to work, no matter how many compiler
DJ Delorie wrote:
Well, that sounds like an autoconf bug. If it refuses to work when
presented with a pile of compiler options, that just sounds bad.
No, I think it's our bug - we do this:
GCC_NO_EXECUTABLES
GLIBCXX_ENABLE_SYMVERS([yes])
You can't logically expect that to work, no
I see -- but why did we set GCC_NO_EXECUTABLES? Don't we only do that
when we've failed to link things?
No, it's explicit:
if test $build != $host; then
# We are being configured with some form of cross compiler.
GLIBCXX_IS_NATIVE=false
case $host,$target in
DJ Delorie wrote:
I see -- but why did we set GCC_NO_EXECUTABLES? Don't we only do that
when we've failed to link things?
No, it's explicit:
I apologize; I didn't realize that. In that case, you're right; the
current approach is just busted. It should become an --enable option,
or a
On Fri, 28 Apr 2006, DJ Delorie wrote:
I see -- but why did we set GCC_NO_EXECUTABLES? Don't we only do that
when we've failed to link things?
No, it's explicit:
if test $build != $host; then
# We are being configured with some form of cross compiler.
GLIBCXX_IS_NATIVE=false
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello all,
Its my first message to the list.
I am happy for this year found the FSF, and more especially, the gcc
project, in the Google Summer of Code[1].
Let me introduce myself, I'm 23 years old Brazilian student of
Management, but I also did a
On Fri, Apr 28, 2006 at 08:36:50PM -0400, DJ Delorie wrote:
Well, that sounds like an autoconf bug. If it refuses to work when
presented with a pile of compiler options, that just sounds bad.
No, I think it's our bug - we do this:
GCC_NO_EXECUTABLES
GLIBCXX_ENABLE_SYMVERS([yes])
What are you building here? A combined tree including newlib? If
so, I bet you aren't specifying --with-newlib; that turns off a
bunch
The toplevel configure automatically adds that in a combined tree (or
at least it should), if newlib is being built.
The two targets I'm currently working
I apologize; I didn't realize that. In that case, you're right; the
current approach is just busted. It should become an --enable option,
or a hard-coded case statement, or an autoconf test that doesn't require
linking stuff.
Really? Like --enable-symvers[=style]?
Eder wrote:
Partial Transitions[http://gcc.gnu.org/wiki/Partial%20Transitions]
called my attention.
I am very interested in submitting a project for the SoC in this category.
I read the general ideas and have a project in my mind to execute the
task listed in the wiki.
You might want to
On Fri, Apr 28, 2006 at 11:21:18PM -0400, DJ Delorie wrote:
What are you building here? A combined tree including newlib? If
so, I bet you aren't specifying --with-newlib; that turns off a
bunch
The toplevel configure automatically adds that in a combined tree (or
at least it
--- Comment #3 from johnzhang at tencent dot com 2006-04-28 06:36 ---
Ok, you are right. it would be nice if g++ 4.1.0 acts as what g++ 3.3.4 does.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27257
--- Comment #6 from patchapp at dberlin dot org 2006-04-28 08:00 ---
Subject: Bug number PR24813
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-04/msg01075.html
--
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-04-28 08:44 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01078.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from guillaume dot melquiond at ens-lyon dot fr 2006-04-28
09:03 ---
I tried setting the nonnull attribute, it indeed allowed the optimization. In
particular, codes containing dynamic casts are now straight lines. This is a
nice improvement. Unfortunately GCC was not
--- Comment #3 from patchapp at dberlin dot org 2006-04-28 09:15 ---
Subject: Bug number PR27269
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-04/msg01079.html
--
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-28 09:33 ---
VRP could extract this information just like it does for loads in
void bar(int);
int foo(int *i)
{
bar(*i);
return i == NULL;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27336
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
$ cat exp.cpp
templateclass T struct type_name { static char const name[]; };
templateclass T char const type_nameT::name[] = ;
template char const type_nameint::name[] = int;
$ g++ -v exp.cpp
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr
--- Comment #2 from marc dot glisse at normalesup dot org 2006-04-28 10:33
---
(In reply to comment #1)
Both libc and libstdc++ are considered part of the implementation which means
both are valid to use this name space.
Which means both should take care not to use a name (in this
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-04-28 11:43
---
Subject: Bug 27218
Author: rguenth
Date: Fri Apr 28 11:43:43 2006
New Revision: 113343
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113343
Log:
2006-04-28 Andrew Pinski [EMAIL PROTECTED]
Richard
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-04-28 11:43 ---
Subject: Bug 27236
Author: rguenth
Date: Fri Apr 28 11:43:43 2006
New Revision: 113343
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113343
Log:
2006-04-28 Andrew Pinski [EMAIL PROTECTED]
Richard
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-04-28 11:43
---
Subject: Bug 26869
Author: rguenth
Date: Fri Apr 28 11:43:43 2006
New Revision: 113343
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113343
Log:
2006-04-28 Andrew Pinski [EMAIL PROTECTED]
Richard
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
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-04-28 12:11
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-04-28 12:11
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-04-28 12:12
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-28 13:33 ---
Confirmed. Regression with the new C++ parser.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-28 13:36 ---
In this particular case this should not happen as the memcmp is guarded by the
length comparison before.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27348
--- Comment #3 from fnf at specifix dot com 2006-04-28 13:54 ---
Subject: Re: memcmp reads past end of strings
On Friday 28 April 2006 09:36, rguenth at gcc dot gnu dot org wrote:
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-28 13:36
---
In this particular
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-04-28 14:06 ---
This is really because we do not decompose structs pointed to by parameters for
their elements, so a write to an int clobbers all of plan7_s.
With -O2 timings on i686 are for me (averages of three runs)
3.4.6
--
Summary: Fortran function returns are not correct in c on X86_64
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
gcc3.4.4 on x86_64
When a c program calls a fortran function which returns a real value
the c program gets the wrong answer.
--
Summary: Fortran function returns are not correct in c on X86_64
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
--- Comment #1 from ray at ultramarine dot com 2006-04-28 14:25 ---
Created an attachment (id=11343)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11343action=view)
All necessary files to produce the bug
go is a csh script that compiles the fortran, compiles the c, links and runs.
I got
[EMAIL PROTECTED] 0001]$ /usr/gcc-4.2/bin/gcc -ffixed-form
-ffixed-line-length-132 -O2 bifoag.f90 -c
bifoag.f90: In function âbifoagâ:
bifoag.f90:127: internal compiler error: in gfc_conv_array_transpose, at
fortran/trans-array.c:726
Please submit a full bug report,
with preprocessed
--- Comment #11 from patchapp at dberlin dot org 2006-04-28 14:35 ---
Subject: Bug number PR26726
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-04/msg01095.html
--
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-04-28 14:36
---
Subject: Bug 26826
Author: rguenth
Date: Fri Apr 28 14:36:14 2006
New Revision: 113348
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113348
Log:
2006-04-28 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-04-28 14:40
---
Subject: Bug 26826
Author: rguenth
Date: Fri Apr 28 14:40:51 2006
New Revision: 113349
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113349
Log:
2006-04-28 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-28 14:46 ---
*** This bug has been marked as a duplicate of 27350 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-28 14:46 ---
*** Bug 27349 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27350
With the attached testcase, SecurityManager.checkPermission() is called three
times when it should only be called once. In genral, we make far too many
invocations of SecurityManager.checkPermission().
--
Summary: SecurityManager.checkPermission() called unnecessarily
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-28 15:02 ---
Confirmed with 3.3-hammer. Fortran returns as double if using xmm registers,
so your C prototype is wrong in this case. It is fixed with gfortran in 4.1.0
at least, and 3.4 is no longer maintained.
--
rguenth
--- Comment #2 from Georg dot Baum at post dot rwth-aachen dot de
2006-04-28 15:05 ---
The patch at http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01084.html fixes the
problem for me. Now my code compiles without optimization, but with -O1 or
higher I get a different ICE without file
--- Comment #2 from jakub at gcc dot gnu dot org 2006-04-28 15:07 ---
One incremental fix for the global var case is:
--- omp-low.c.jj5 2006-04-28 13:29:49.0 +0200
+++ omp-low.c 2006-04-28 16:22:36.0 +0200
@@ -674,9 +674,6 @@ omp_copy_decl (tree var,
--- Comment #1 from aph at gcc dot gnu dot org 2006-04-28 15:16 ---
Created an attachment (id=11344)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11344action=view)
Test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27352
--- Comment #2 from aph at gcc dot gnu dot org 2006-04-28 15:18 ---
The output of this test should be something like:
java.lang.Throwable
at MySecurityManager.checkPermission(t.java:33)
at java.lang.Class.getClassLoader(Class.java:580)
at trial.x(trial.java:5)
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-28 16:29 ---
(In reply to comment #3)
Ok, you are right. it would be nice if g++ 4.1.0 acts as what g++ 3.3.4 does.
Use -fwrapv if you want defined wrapping.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27257
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-28 16:34 ---
We need a testcase, not every one has access to galgel.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2006-04-28 16:38 ---
Doesn't seem to be openmp specific:
struct A
!
{
templateint void foo();
};
template void A::foo0();
ICEs the same way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27315
--- Comment #2 from jakub at gcc dot gnu dot org 2006-04-28 16:39 ---
Doesn't seem to be openmp specific.
struct A {};
struct B : A
!
{};
struct B : A
!
{};
ICEs the same way.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2006-04-28 16:42 ---
Neither of the testcases are openmp specific, after
s/#pragma omp parallel/!/g
they crash the same way without -fopenmp.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-28 16:44 ---
Then this is a regression since that testcase did not produce an ICE in 3.4.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from malitzke at metronets dot com 2006-04-28 16:46 ---
After compiling gcc-4.1.1 successfully on a powerpc and another pentium3
machine it appears that the problem reported was due to bit-rot in the server
and not caught by svn updates. This appears to be confirmed by
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-28 16:46 ---
This does not ICE with checking turned off and it has failed since 3.4.0 (and I
don't have a checking build before the 3.4.0).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-28 16:48 ---
Confirmed, a regression from at least 3.4.0 (I have only a 4.0.0 right before
the branch of 4.0).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-28 16:57 ---
This is interesting because this might be a regression as people have run with
valgrind before.
It might also be a valgrind bug.
Or maybe just an off by one bug.
Anyways changing to use strncmp is not correct
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-28 17:39 ---
This is a documentation regression as now, the builtins are inconstaint with
the source.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-28 17:41 ---
This is a dup of bug 25519. SSE3 (and when SSE4 support gets checked in, it
will also have the same issue).
*** This bug has been marked as a duplicate of 25519 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-28 17:41 ---
*** Bug 23218 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hjl at lucon dot org 2006-04-28 17:52 ---
Failed:
gcc version 4.2.0 20060417 (experimental) [trunk revision 113003 clean]
Worked:
gcc version 4.2.0 20060416 (experimental) [trunk revision 112982 clean]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27351
--- Comment #21 from dberlin at gcc dot gnu dot org 2006-04-28 18:26
---
Subject: Bug 26626
Try this patch, it should work :)
--- Comment #22 from dberlin at gcc dot gnu dot org 2006-04-28 18:26
---
Created an attachment (id=11345)
--
--- Comment #3 from hjl at lucon dot org 2006-04-28 18:32 ---
This patch
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00537.html
causes this regression. But galgel doesn't fail on ia64 nor x86-64.
--
hjl at lucon dot org changed:
What|Removed
--- Comment #4 from hjl at lucon dot org 2006-04-28 18:38 ---
Even more interesting, gcc -m32 works fine on x86-64:
[EMAIL PROTECTED] 0001]$ /usr/gcc-4.2/bin/gfortran-ffixed-form
-ffixed-line-length-132 -m32 -O2 bifoag.f90 -S
[EMAIL PROTECTED] 0001]$
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-28 18:57 ---
Looks related to PR 26119 which is hard to reproduce.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-28 19:02 ---
Actually I thought you were using valgrind. Anyways this is a mudflap issue so
reopening since mudflap is part of GCC.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from dnovillo at gcc dot gnu dot org 2006-04-28 19:02
---
(In reply to comment #0)
The gimplifier should not be emitting errors.
Why, exactly? Some diagnostics are impossible to emit early enough. Is this a
documented requirement? What's the rationale?
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-28 19:05 ---
(In reply to comment #1)
Why, exactly? Some diagnostics are impossible to emit early enough. Is this
a
documented requirement? What's the rationale?
Read the comments in PR 24222 but basicially the
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-28 19:06 ---
Small testcase:
char a[] = tree.h;
char b[] = treelang;
int main(void)
{
return memcmp (a, b, strlen(b)) != 0;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from dnovillo at gcc dot gnu dot org 2006-04-28 19:17
---
(In reply to comment #2)
Read the comments in PR 24222 but basicially the gimplifier is not should not
being doing any semantic anlyasis, that is the job of the front-end.
Well, some of the structural
--- Comment #3 from dnovillo at gcc dot gnu dot org 2006-04-28 19:17
---
Well, some of the structural analysis for which emit errors is done even later
than that, so it would be naive to pretend that we can catch everything during
parsing.
I don't understand why it is hard.
--- Comment #4 from pinskia at physics dot uc dot edu 2006-04-28 19:20
---
Subject: Re: [4.2 Regression] Some OpenMP semantics are caught too late (in
the gimplifier)
--- Comment #3 from dnovillo at gcc dot gnu dot org 2006-04-28 19:17
---
Well, some of the
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-28 19:26 ---
The code is invalid. Anybody knows a trick to have a POD storage for non-POD
n-dimensional object which individual elements can be accessed using a
specialized 1-dimensional non-POD object? POD storage to avoid
--- Comment #7 from sayle at gcc dot gnu dot org 2006-04-28 20:00 ---
Subject: Bug 25309
Author: sayle
Date: Fri Apr 28 19:59:57 2006
New Revision: 113355
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113355
Log:
PR c/25309
* c-typeck.c (struct spelling): Make I
--- Comment #3 from pcarlini at suse dot de 2006-04-28 20:01 ---
(In reply to comment #2)
(In reply to comment #1)
Both libc and libstdc++ are considered part of the implementation which
means
both are valid to use this name space.
Which means both should take care not to use
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-28 20:22 ---
Ok, this one does it, just for the curious:
template int Dim
struct Loc;
struct LocStorage
{
int x;
};
template
struct Loc1 : public LocStorage
{
Loc() {}
Loc(int i) { this-x = i; }
Loc1 operator[](int)
--- Comment #4 from marc dot glisse at normalesup dot org 2006-04-28 20:43
---
(In reply to comment #3)
Well, I think Andrew has a point: suppose we rename all those functions to
_M_cos and co. Then, later, we discover that a third libc (not Solaris, not
GNU) conflicts with those
--- Comment #5 from pcarlini at suse dot de 2006-04-28 21:18 ---
(In reply to comment #4)
Convinced of what?
Of course convinced that before renaming and re-renaming (endlessly, in
principle) we should really give some serious tought to those issues, figure
out what we are trying to
1 - 100 of 126 matches
Mail list logo
