--- Comment #3 from jvdelisle at gcc dot gnu dot org 2005-10-30 07:07
---
The patch in the original post is wrong. The patch in comment #2 is correct
and is very similar to the patch done for pr16080 for which the test case
read_null_string.f90 was made.
--
http://gcc.gnu.org/bugz
--- Comment #9 from rpjday at mindspring dot com 2005-10-30 09:56 ---
The latest snapshot of gcc-4.1-20051029 still produces the same error at the
same location. Was there a workaround posted somewhere, or is this still an
unresolved issue?
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #8 from hubicka at gcc dot gnu dot org 2005-10-30 09:59 ---
Subject: Bug 24093
Author: hubicka
Date: Sun Oct 30 09:59:16 2005
New Revision: 106014
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106014
Log:
PR middle-end/24093
* ipa-inline.c (craph_dec
--- Comment #2 from greenrd at gcc dot gnu dot org 2005-10-30 12:00 ---
The real problem here was that I had a typo in my /etc/hosts, so the hostname
could not be resolved. I've updated the bug summary.
GNU classpath 0.18 implements the correct behaviour:
$ jamvm TestAddr
java.net.Unkn
--- Comment #24 from fxcoudert at gcc dot gnu dot org 2005-10-30 12:48
---
Subject: Bug 20179
Author: fxcoudert
Date: Sun Oct 30 12:48:52 2005
New Revision: 106017
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106017
Log:
PR libfortran/20179
* io/unix.c (flush_
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-10-30 13:02
---
Confirmed on i686-linux for mainline. The option that triggers this problem is
-fbounds-check.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pcarlini at suse dot de 2005-10-30 13:02 ---
This is not a libstdc++-v3 problem. What happens on 4_0-branch is that among
the global strings declared in language.cc and initialized in define_strings(),
when init_game() returns only the first five are ok, the remaining
--- Comment #25 from fxcoudert at gcc dot gnu dot org 2005-10-30 13:25
---
Subject: Bug 20179
Author: fxcoudert
Date: Sun Oct 30 13:25:25 2005
New Revision: 106018
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106018
Log:
PR libfortran/20179
* io/unix.c (flush_
--- Comment #3 from pcarlini at suse dot de 2005-10-30 13:39 ---
I'm closing the PR as invalid: there is a nasty bug in the code: the loop in
init_game() runs up to 8 instead of the correct 7, thus probably overwriting
memory allocated to the strings.
--
pcarlini at suse dot de chang
--- Comment #26 from fxcoudert at gcc dot gnu dot org 2005-10-30 13:49
---
Finally fixed by the last two commits (on both 4.0 and 4.1).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-30 15:14 ---
So this is fixed in 4.1.0?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24583
Seems to happen with 3.3,3.4,
Short test case courtesy of A.Pinski:
static void __attribute__ ((__section__ (".init.text"))) pci_fixup_i450nx(void)
{ }
static int __attribute__ ((__section__ (".init.text")))
toshiba_ohci1394_dmi_table[] = { };
causes with gcc (without -O2);
t.c:4: error: tosh
--- Comment #1 from ak at muc dot de 2005-10-30 15:56 ---
Created an attachment (id=10081)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10081&action=view)
Long test case directly from Linux kernel, shows the error in more
circumstances
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #2 from pluto at agmk dot net 2005-10-30 16:12 ---
(In reply to comment #0)
> Seems to happen with 3.3,3.4,
>
> Short test case courtesy of A.Pinski:
>
> static void __attribute__ ((__section__ (".init.text")))
> pci_fixup_i450nx(void)
> { }
> static int __attribute__ ((_
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-30 16:13 ---
Confirmed for the short testcase at -O0. Finding one for the -O2 issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-30 16:18 ---
I wonder if this is really a regression at all here is the testcase for -O2:
struct pci_fixup {
void (*hook)(void);
};
static void __attribute__ ((__section__ (".init.text")))
pci_fixup_ide_bases(void) {}
static cons
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-30 16:32 ---
Fixed for 4.1.0 so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from hp at gcc dot gnu dot org 2005-10-30 16:46 ---
Subject: Bug 18482
Author: hp
Date: Sun Oct 30 16:46:41 2005
New Revision: 106026
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106026
Log:
PR target/18482
* gcc.dg/compat/struct-layout-1_generat
--- Comment #7 from hp at gcc dot gnu dot org 2005-10-30 17:00 ---
"Fixed" by passing -mno-base-addresses.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-30 17:10 ---
Supending until the other bugs like this is fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-30 17:13 ---
This works for other people on AIX without any trouble.
Can you try again with a newer gcc and see if you can reproduce it?
Also can you make sure that libraries and headers match in version?
--
pinskia at gcc do
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-30 17:14 ---
Does this work now?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-30 17:17 ---
Why do you want a compiler which is built in 64bit mode, it will not default to
64bit mode? It will be slower and hug more memory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23101
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-30 17:27 ---
Fixed in 4.0.0 and above by inlining __builtin_copysign all the time.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
Jakub, the testcase g++.dg/opt/mmx2.C you added, causes a segfault
on the 4.0 branch:
g++ -O2 -mmmx -c mmx2.C
mmx2.C: In function 'int main()':
mmx2.C:23: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bu
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||error-recovery
Target Milestone|--- |4.1.0
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-30 17:37 ---
Reduced testcase:
JigdoFileCmd::Command ::JigdoFileCmd::cmdOptions(int argc, char* argv[]) {
switch (c) {
case LONGOPT_BZIP2: optBzip2 = true;
---
This is not mine after all.
--
pinskia at gcc
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-30 17:42 ---
(In reply to comment #3)
> This is not mine after all.
As this was introduced before my patch which I had thought might had caused it.
This was caused by:
2005-10-13 Mark Mitchell <[EMAIL PROTECTED]>
PR c
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-30 17:55
---
So did it work after using GNU tar?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24562
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-30 17:55 ---
Can you attach the source?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-30 17:57 ---
Also how did you configure gcc and how did you invoke make?
If this is building for a native compiler, can you try "make bootstrap"?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24563
--- Comment #16 from hubicka at gcc dot gnu dot org 2005-10-30 18:00
---
testing fix that should make legitimize_pic_address correctly decompose the
address. Similar to Steven's but I think it actually works ;)
Index: config/i386/i386.c
==
When a new version of GNU Classpath is imported gnu.classpath.version should be
set by libgcj to indicate which version of GNU Classpath it is using. This is
used in a couple of places (for example the http.agent property).
--
Summary: libgcj should set gnu.classpath.version system pr
--- Comment #14 from hubicka at gcc dot gnu dot org 2005-10-30 18:18
---
Subject: Bug 24172
Author: hubicka
Date: Sun Oct 30 18:14:15 2005
New Revision: 106247
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106247
Log:
PR tree-optimization/24172
* tree-inline.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-30 18:35 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #15 from thebohemian at gmx dot net 2005-10-30 19:14 ---
Created an attachment (id=10082)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10082&action=view)
proposed fix
This patch includes all the lazyfications and a fix for to_array() involving
primitive array names wh
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2005-10-30 19:27
---
I hadn't seen that bug before now. I'll give it a try when i next reboot my
computer (i don't see the ICE on a cross-compiler).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
#include
template
class A {
public:
class iterator {
E dummy;
};
iterator iter;
};
template< typename E>
void sort( typename A::iterator& first, typename A::iterator& last ) {
std::cout << "sort" << std::endl;
}
int main( int argc, char *argv[] ) {
A firs
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-30 20:59 ---
I don't think this is a bug. What is happening is that compiler cannot figure
out that you want sort as there are no agruments to sort which is based on
the template agrument (except for ones which are dependent on
--- Comment #2 from igodard at pacbell dot net 2005-10-30 21:29 ---
I don't get it. The argument is A::iterator, which surely depends on
A::iterator (with "E" taken as "int"). The problem also arises in the
simpler case:
#include
template
class A {
public:
class iterator {
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18482
--- Comment #34 from mmitchel at gcc dot gnu dot org 2005-10-30 21:43
---
This is a usability issue (and, maybe, a pedantic standards-conformance
issue?), but is not release-critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #60 from mmitchel at gcc dot gnu dot org 2005-10-30 21:45
---
I'd like to fix this for 4.1, but not at the expense of destabilizing things,
or losing performance.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from hubicka at gcc dot gnu dot org 2005-10-30 21:59
---
Fixed by my patch
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #24 from mmitchel at gcc dot gnu dot org 2005-10-30 22:03
---
There's no evidence that this affects any of the primary languages, so set to
P5.
(At one point the target milestone on this PR was removed, but at some point it
came back.)
--
mmitchel at gcc dot gnu dot org
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-30 22:07
---
I've talked about this with EDG. The reason they reject the test case is that
Y::I might or might not be X::I, depending on whether or not there
are specializations of Y in play. I agree with this logic, so the t
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20495
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21309
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21283
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22127
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.0 |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21512
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23492
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14798
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15065
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15212
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17729
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
Target Milestone|--- |4.1.0
http://gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18456
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P5
Target Milestone|--- |4.1.0
http://gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P5
Target Milestone|--- |4.1.0
http://gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P5
Target Milestone|--- |4.1.0
http://gcc
--- Comment #44 from mmitchel at gcc dot gnu dot org 2005-10-30 22:13
---
We don't have clear evidence that this is worse, let alone substantially worse,
than previous releases. Until and unless we do, I've downgraded this to P4.
However, if this is fixed, let's just mark it so, and mo
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P5
Target Milestone|--- |4.1.0
http://gcc
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-30 22:16
---
We need new infrastructure to fix accepts-invalid access-control issues in
templates.
I removed the target milestone on this PR once before, but Andrew Pinksi put it
back. Now, I've downgraded this to P5.
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P5
Target Milestone|--- |4.1.0
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P5
Target Milestone|--- |4.1.0
--- Comment #14 from mmitchel at gcc dot gnu dot org 2005-10-30 22:23
---
We now have --build-sysroot, which ameliorates this situation.
(I don't fully understand Alexandre's suggestion, in the message linked from
Comment #13.)
In any case, I've downgraded this to P5, as, although cle
--- Comment #2 from pcarlini at suse dot de 2005-10-30 22:25 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from mmitchel at gcc dot gnu dot org 2005-10-30 22:26
---
Downgraded to P5.
I don't think this missed-optimization on the Pentium Pro (now a relatively old
CPU) is release-critical, especially since we think that the change that caused
the problem was generally benefici
--- Comment #22 from mmitchel at gcc dot gnu dot org 2005-10-30 22:31
---
According to the data in Comment #19, we're now better on some cases, and worse
on others. I'd suggest we just close this PR.
However, in the meanwhile, I've downgraded this to P4. A small compile-time
increase
--- Comment #15 from mark at codesourcery dot com 2005-10-30 22:33 ---
Subject: Re: [3.4/4.0/4.1 regression] Minor compilation
problem for cross to Solaris 8
What's this "4.1blocker-" stuff about? This certainly isn't a 4.1
blocker, and that information is already computable from the
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-10-30 22:36
---
(In reply to comment #15)
> Subject: Re: [3.4/4.0/4.1 regression] Minor compilation
> problem for cross to Solaris 8
> What's this "4.1blocker-" stuff about? This certainly isn't a 4.1
> blocker, and that inform
--- Comment #13 from mmitchel at gcc dot gnu dot org 2005-10-30 22:38
---
Set to P2; I'd like to fix this, if possible, since it's hard enough to write
extended asm code without getting ICEs.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed
--- Comment #17 from mark at codesourcery dot com 2005-10-30 22:38 ---
Subject: Re: [3.4/4.0/4.1 regression] Minor compilation
problem for cross to Solaris 8
pinskia at gcc dot gnu dot org wrote:
> --- Comment #16 from pinskia at gcc dot gnu dot org 2005-10-30 22:36
> ---
>
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-30 22:41
---
To better support restrict, we should copy around the set of "based on"
pointers when copying other pointer attributes.
However, I don't think this is a sufficiently serious missed optimization to
warrant holding
--- Comment #8 from eedelman at gcc dot gnu dot org 2005-10-30 22:43
---
Subject: Bug 18883
Author: eedelman
Date: Sun Oct 30 22:43:45 2005
New Revision: 106254
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106254
Log:
fortran/
2005-10-30 Erik Edelmann <[EMAIL PROTECTED]>
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-30 22:44
---
P2 is the right setting for this bug; it's popping up often enough to make it
worth fixing. Disabling the inlining in the case that the argument type
doesn't match (closely enough) the parameter type seems reasona
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-30 22:47
---
Marked as P5; I don't think missed-optimizations depending on "restrict" are
release-critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #15 from mmitchel at gcc dot gnu dot org 2005-10-30 22:50
---
Reduced to P5; until David decides this is sufficiently important, there's no
reason to hold up a release for this PR.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from mmitchel at gcc dot gnu dot org 2005-10-30 22:51
---
Leaving as P2; we should try to fix this, but it's not a showstopper.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17256
--- Comment #21 from mmitchel at gcc dot gnu dot org 2005-10-30 22:53
---
Leaving as P2; as stated in the audit trail, this problem has the potential to
seriously confuse people.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17506
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-30 22:55
---
Leaving as P2; we should at least try to figure out whether we really want to
give a warning here.
(I suspect we may end up closing this PR as INVALID, because the non-PODness
does affect things -- like whether
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22127
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P5
Target Milestone|--- |4.1.0
http://gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
Target Milestone|--- |4.1.0
http://gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
Target Milestone|--- |4.1.0
http://gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P5
Target Milestone|--- |4.1.0
http://gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
Target Milestone|--- |4.1.0
http://gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
Target Milestone|--- |4.1.0
http://gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P5
Target Milestone|--- |4.1.0
http://gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P5
Target Milestone|--- |4.1.0
http://gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P5
Target Milestone|--- |4.1.0
http://gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P5
Target Milestone|--- |4.1.0
http://gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P5
Target Milestone|--- |4.1.0
http://gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P5
Target Milestone|--- |4.1.0
http://gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P5
Target Milestone|--- |4.1.0
http://gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P5
Target Milestone|--- |4.1.0
http://gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P5
Target Milestone|--- |4.1.0
http://gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P5
Target Milestone|--- |4.1.0
http://gcc
1 - 100 of 325 matches
Mail list logo