--- Comment #15 from mark at codesourcery dot com 2006-07-19 06:00 ---
Subject: Re: [4.0 Regression] rejects valid code with some
extern C
tbm at cyrius dot com wrote:
So apparently this is invalid code. However, I feel very strongly that a
point
release of GCC should *not*
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-07-19 06:43
---
Subject: Bug 28048
Author: mmitchel
Date: Wed Jul 19 06:42:56 2006
New Revision: 115581
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115581
Log:
PR c++/28048
* semantics.c
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-07-19 06:43
---
Fixed in 4.1.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-19 09:39 ---
This is a bug in your code and not in libobjc or GCC.
The correct code should look like:
#include objc/Object.h
#include stdio.h
#include string.h
int main()
{
char s[80];
char *d = s;
strcpy(s,Hi
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-07-19 09:51
---
Fixed at least on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-07-19 09:58
---
Fixed on mainline and 4.1 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-07-19 10:03
---
Fixed on mainline, 4.1 branch, and 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
libgomp fails to build on GNU/Hurd:
/build/buildd/gcc-snapshot-20060613/build/./gcc/xgcc
-B/build/buildd/gcc-snapshot-20060613/build/./gcc/
-B/usr/lib/gcc-snapshot/i486-gnu/bin/ -B/usr/lib/gcc-snapshot/i486-gnu/lib/
-isystem /usr/lib/gcc-snapshot/i486-gnu/include -isystem
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-19 10:34 ---
It was fixed the next day after that snapshot.
June 13th snapshot is a month old already anyways.
*** This bug has been marked as a duplicate of 28008 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-07-19 10:34 ---
*** Bug 28431 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Since today, I get some duplicate diagnostics:
==
struct A {};
void A::foo();
==
bug.cc:2: error: no 'void A::foo()' member function declared in class 'A'
bug.cc:2: error: no 'void A::foo()' member function declared in class 'A'
bug.cc:2: error:
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-07-19 10:50
---
The duplicate message reappeared yesterday (but not the bogus stuff).
This is tracked in PR 28432.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25635
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-07-19 11:04
---
Because of Steve's patch for PR28304 we now get the following message
for the second testcase:
bug.cc:3: error: no 'void A::foo()' member function declared in class 'A'
bug.cc:3: error: no 'void A::foo()' member
[EMAIL PROTECTED]:/tmp$ gcc objc_float_bug.m -lobjc
[EMAIL PROTECTED]:/tmp$ ./a.out
objc_write_type: cannot parse typespec: f
Aborted
[EMAIL PROTECTED]:/tmp$ cat objc_float_bug.m
#include objc/Object.h
int main()
{
float x=1.25;
TypedStream* stream =
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-19 11:12 ---
Right, it was never did.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-07-19 11:40
---
Here's a slightly shorter testcase:
=
struct A
{
char c[13];
int k[1];
};
struct A a[1];
void foo(int* p)
{
int i, j;
for (i=0; i2; ++i)
if (memcmp (a[i].k,
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
|
--- Comment #21 from reichelt at gcc dot gnu dot org 2006-07-19 12:44
---
I cannot reproduce the ICE with the original testcase.
I can reproduce it with the testcase from comment #19 and #20, though.
Here's an even shorter version:
===
void foo();
static inline
The following invalid testcase triggers an ICE since GCC 4.1.0
(when objective-c++ was introduced):
Class c;
bug.mm:1: error: expected identifier before '' token
bug.mm:1: internal compiler error: tree check: expected identifier_node, have
error_mark in
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-07-19 13:19
---
I see what the problem is. cgraph_postorder doesn't help us if we're having a
cycle like here, so
nnodes = cgraph_postorder (order);
for (i = nnodes - 1; i = 0; i--)
{
node = order[i];
if
--- Comment #1 from patchapp at dberlin dot org 2006-07-19 13:20 ---
Subject: Bug number PR obj-c++/28434
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/msg00813.html
--
--- Comment #23 from rguenth at gcc dot gnu dot org 2006-07-19 13:31
---
I have a patch:
Index: ipa-inline.c
===
--- ipa-inline.c(revision 115554)
+++ ipa-inline.c(working copy)
@@ -1133,6 +1133,7 @@
--- Comment #24 from rguenth at gcc dot gnu dot org 2006-07-19 13:59
---
Hmm, it needs to find the root of the callgraph first. Or all root nodes, and
find cycles starting from there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27882
I really don't know if this is a bug or not but it seems to be.
The steps to reproduce:
mkdir sys
cat sys/t.h FOO
#include bogus.h
FOO
cat t.c FOO
#include t.h
FOO
gcc -isystem sys t.c -MMD
And notice that this actually compiles successfully even though bougs.h does
not exist. And removing the
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-19 14:06 ---
I forgot to say every GCC since at least 2.95.3, I tried has the same behavior.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28435
--- Comment #25 from rguenth at gcc dot gnu dot org 2006-07-19 14:06
---
Simpler one goes along
@@ -1148,9 +1149,13 @@ cgraph_early_inlining (void)
if (node-analyzed node-local.inlinable
(node-needed || node-reachable)
node-callers)
+ inlined |=
Just like PR 28367:
#define vector __attribute__((vector_size(16)))
float f(vector float t)
{
return *(float*)t;
}
We get a full vector store which we can get around with a stvewx which just
stores that one element and we can get that via a vec_extract pattern.
On x86_64 has the same issue,
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-19 14:17 ---
I have a patch to fix this and other bugs that show up because of the more uses
of vec_set/vec_extract which I will submit when I get back in the US.
--
pinskia at gcc dot gnu dot org changed:
What
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28436
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-19 14:46 ---
(In reply to comment #2)
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 after my patch too).
And
If more than one -fno-builtin-* flag is specified, the first one is ignored.
I've seen other reports of this on Wine the mailing lists. We use -fno-builtin
to supress the gcc builtins that are incompatible with msvcrt's string
functions.
[EMAIL PROTECTED]:~/wine$ cat b.c
int iswalpha(unsigned
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-19 15:31 ---
This is a regression, 4.0.0 worked so did some prerelease versions of 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Both KDE and OOo fail to build with the anon namespace not exported changes.
A short testcase of what they are doing:
cat test.h EOF
namespace { struct A {}; }
struct B
{
A *a;
B ();
};
EOF
cat test1.C EOF
#include test.h
B::B () : a(0)
{
}
B b;
int
main (void)
{
}
EOF
cat test2.C EOF
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-19 15:45 ---
B violates ODR rules as the class for A is different between the TUs as it is
in an anon namespace.
See PR 28360 for full details.
*** This bug has been marked as a duplicate of 28360 ***
--
pinskia at gcc dot
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-19 15:45 ---
*** Bug 28438 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from patchapp at dberlin dot org 2006-07-19 15:55 ---
Subject: Bug number PR 27919
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/msg00817.html
--
--- Comment #3 from vda dot linux at googlemail dot com 2006-07-19 16:24
---
I instrumented choose_multiplier(). When called like this:
choose_multiplier(d=1577682821,n=32,precision=32),
it returns *post_shift_ptr=31,multiplier=5846151023
whereas optimal one is
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-07-19 16:34 ---
This more important with the Cell than most other PowerPCs.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from janis at gcc dot gnu dot org 2006-07-19 16:51 ---
This can be closed, either as fixing the test case or as will not fix for
detecting in the compiler that the initialization could be done at compile
time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28113
--- Comment #4 from jb at gcc dot gnu dot org 2006-07-19 16:52 ---
Subject: Bug 27919
Author: jb
Date: Wed Jul 19 16:51:49 2006
New Revision: 115593
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115593
Log:
2006-07-19 Janne Blomqvist [EMAIL PROTECTED]
PR fortran/27919
--- Comment #5 from jb at gcc dot gnu dot org 2006-07-19 16:52 ---
Subject: Bug 27919
Author: jb
Date: Wed Jul 19 16:52:45 2006
New Revision: 115594
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115594
Log:
2006-07-19 Janne Blomqvist [EMAIL PROTECTED]
PR fortran/27919
The expression/condition in an arithmetic if statement appears to be evaluated
multiple times when it is zero or negative. This is particularly bad when the
expression is a function that depends on input or has state associated with it.
Example:
program lll
integer myfunc
do
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-07-19 17:06
---
This test now passes.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #26 from hubicka at gcc dot gnu dot org 2006-07-19 17:29
---
Well, I don't like much the limiting of inlining in recursive functions (where
it is rather interesting)
and I can't convince myself that the second patch is safe (ie the cycle don't
have to be in consetuctive
--- Comment #1 from mmitchel at gcc dot gnu dot org 2006-07-19 17:31
---
Subject: Bug 28337
Author: mmitchel
Date: Wed Jul 19 17:31:51 2006
New Revision: 115596
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115596
Log:
PR c++/28337
* typeck.c (build_binary_op):
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-07-19 17:32
---
Subject: Bug 28337
Author: mmitchel
Date: Wed Jul 19 17:32:38 2006
New Revision: 115597
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115597
Log:
PR c++/28337
* typeck.c (build_binary_op):
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-07-19 17:35
---
Fixed in 4.1.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-07-19 17:38
---
This test case now works for me on both the 4.1 and 4.2 branches.
Martin, would you please confirm that, at your convenience?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28225
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
cc -O2 -fno-strict-aliasing -pipe
-I/usr/obj/usr/src/tmp/legacy/usr/include -c
/usr/src/games/fortune/strfile/strfile.c
In file included from /usr/include/sys/types.h:44,
from /usr/include/sys/param.h:63,
from /usr/src/games/fortune/strfile/strfile.c:51:
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-07-19 19:56
---
Subject: Bug 28434
Author: reichelt
Date: Wed Jul 19 19:56:29 2006
New Revision: 115599
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115599
Log:
PR obj-c++/28434
* objc-act.c
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-07-19 19:57
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jason at redhat dot com 2006-07-19 20:02 ---
Subject: Re: New: Anon namespace pointers in exported classes
Yes, this is an ODR violation. However, the patch I'm working on will
allow it to compile (as a side effect of other desired changes).
Jason
--
--- Comment #1 from kargl at gcc dot gnu dot org 2006-07-19 20:33 ---
Yep. The dump-tree-original contains
if (myfunc (C.1243) = 0)
{
if (myfunc (C.1243) 0) goto __label_10;
else goto __label_20;
}
else
{
goto
--- Comment #1 from sje at cup dot hp dot com 2006-07-19 20:47 ---
Actually, I think my patch may have been wrong. By adding the return to
check_classfn, what I basically did was to skip the call to add_method, which
according to the comments, is specifically there to add the
--- Comment #6 from jb at gcc dot gnu dot org 2006-07-19 21:13 ---
Above commit remove dot_product from libgfortran, and this this PR should be
fixed.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from echristo at apple dot com 2006-07-19 21:59 ---
I'll take this since I've submitted a patch.
--
echristo at apple dot com changed:
What|Removed |Added
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-07-19 22:49
---
Subject: Bug 28338
Author: mmitchel
Date: Wed Jul 19 22:49:20 2006
New Revision: 115600
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115600
Log:
PR c++/28338
* decl.c (layout_var_decl):
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-07-19 22:51
---
Fixed in 4.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2006-07-19 23:03 ---
Wrong code. Bad.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-19 23:06 ---
The easiest way to fix this is most likely wrap the function call in a
SAVE_EXPR but I could be wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28439
--- Comment #4 from steven at gcc dot gnu dot org 2006-07-19 23:08 ---
Andrew, you're wrong. :-P
My gfortran skills are not what they used to be, but I believe this is the fix:
Index: trans-stmt.c
===
--- trans-stmt.c
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2006-07-19
23:25 ---
I can confirm on MacOS X 10.4 that Steve's proposed patch works fine
with the current gcc trunk. I can successfully bootstrap while
MACOSX_DEPLOYMENT_TARGET is set to 10.4 and no regressions
occur when
--- Comment #9 from mrs at apple dot com 2006-07-19 23:50 ---
We can't define __Unwind_GetIPInfo in libgcc_s.10.5.dylib at this time. If we
create a situation in which we can, rest assured, we will.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|minor |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20407
--- Comment #9 from bass at 2ka dot mipt dot ru 2006-07-20 00:25 ---
I was having a problem related to this one while building gcc on
pentium3-pc-linux-gnu, but I'm not sure whether I should file a separate bug.
Host compiler was gcc-3.4.6, and I passed the ``--enable-regen-headers''
The arc instrumentation code generated by -fprofile-arcs increments
gcov counters in a manner which is not guaranteed to be atomic. As
a result, if two or more cpus enter the same basic block at nearly
the same time they can leave an incorrect arc count, which makes it
impossible for gcov to
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-07-20 01:00
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-20 01:09 ---
Patches go to gcc-patches@ anyways.
Also please read http://gcc.gnu.org/contribute.html if you have not already.
Yes this does legally significant. Oher than I am not a lawyer and this is not
legal advice.
--
--- Comment #2 from gnb at sgi dot com 2006-07-20 01:51 ---
Thanks Andrew,
Also please read http://gcc.gnu.org/contribute.html if you have not already.
I have read that, and while it does mention all the requirements it left
me confused about I should do to start the process. Should
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||gcc-bugs at gcc dot gnu dot
|
--- Comment #1 from dannysmith at users dot sourceforge dot net 2006-07-20
02:31 ---
The bug appears to be that subtarget is just too mean with MAX_OFILE_ALIGNMENT.
Testing some (much) larger values.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu
|
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-07-20 02:55
---
Subject: Bug 28338
Author: mmitchel
Date: Thu Jul 20 02:55:24 2006
New Revision: 115606
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115606
Log:
PR c++/28338
* decl.c (layout_var_decl):
--- Comment #9 from uwe at netbsd dot org 2006-07-20 03:27 ---
(In reply to comment #8)
Author: sayle
Date: Wed Jul 19 05:13:56 2006
New Revision: 115578
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115578
Log:
PR middle-end/28283
* expmed.c
--- Comment #3 from bangerth at dealii dot org 2006-07-20 03:45 ---
That's an important contribution, and I want to encourage you not to get
discouraged by the lengthy process of getting a copyright assignment and
then patch review. Please hang tight, this is a patch that others will
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-07-20 03:59
---
I do not believe this is a bug. The problematic conversion is:
SdOptionsPrint rOldUnconst = (SdOptionsPrint)(rOther);
Here, rOther is declared as:
const SdOptionsPrintItem rOther
and SdOptionsPrintItem
--- Comment #4 from patchapp at dberlin dot org 2006-07-20 04:10 ---
Subject: Bug number PR28339
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/msg00841.html
--
--- Comment #5 from kargl at gcc dot gnu dot org 2006-07-20 04:37 ---
(In reply to comment #4)
My gfortran skills are not what they used to be,
You're always welcomed to spend some quality time with the
gfortran source code :-)
but I believe this is the fix:
Index: trans-stmt.c
80 matches
Mail list logo
