Both
Target: i686-pc-linux-gnu
Configured with: ../configure --disable-nls --with-dwarf2
Thread model: posix
gcc version 4.0.2
and
Target: avr
Configured with: ../configure --prefix=/usr/local/avr --target=avr
--disable-nls --with-dwarf2 --enable-languages=c
Thread model: single
gcc version
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-28 16:50 ---
I don't think this is a bug as the unused global variables are removed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
In using crosstool to build a cross-compiler for the SH3, I get the following
error in building the early bootstrap gcc:
/home/rpjday/results/edge/build-tools/build-gcc-core/./gcc/xgcc
-B/home/rpjday/results/edge/build-tools/build-gcc-core/./gcc/
--- Comment #15 from steven at gcc dot gnu dot org 2005-10-28 16:59 ---
The trouble appears to come from this:
case V16QImode:
case V8HImode:
case V4SFmode:
case V4SImode:
case V4HImode:
case V2SFmode:
case V2SImode:
case V1DImode:
if (CONSTANT_P
--- Comment #1 from rpjday at mindspring dot com 2005-10-28 17:00 ---
Created an attachment (id=10078)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10078action=view)
A script that generates the error described by this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24571
--- Comment #16 from steven at gcc dot gnu dot org 2005-10-28 17:01 ---
On IRC it was suggested that we just need to get a version of
easy_vector_constant which does the right thing in any mode.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24230
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-28 17:01 ---
This is not a bug as you need to install glibc's headers.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
seen with 4.0 CVS 20051023, compiling antlr 2.7.5.
/usr/bin/gcj-4.0 -shared --classpath= -fassume-compiled -I./src -I.
-I/usr/share/java/antlr.jar -I. -g -O2 -c -o antlr.so /usr/share/java/antlr.jar
antlr/StringUtils.java: In class 'antlr.StringUtils':
antlr/StringUtils.java: In method
--- Comment #2 from tomas dot vanek at fbl dot cz 2005-10-28 17:14 ---
I'm sure it is. I have to declare variables in other segment than .data
for my AVR project and if they are declared in one module and __used__ in some
others, they cannot be showed in gdb and AVRstudio (however they
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-28 17:18 ---
never mind, I read unused and I thought unused static variables.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24570
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-28 17:23 ---
Confirmed, only on the 4.0 branch. It works in 3.4.x and also on the mainline.
This is on x86_64-linux-gnu too.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-28 17:24 ---
That is the mainline and 3.4.x give:
.ascii unused_variable\0 # DW_AT_name
.byte 0x1 # DW_AT_decl_file
.byte 0x2 # DW_AT_decl_line
.long 0x7c# DW_AT_type
* the exact version of GCC;
g++ (GCC) 3.3.5 (Debian 1:3.3.5-13)
* the system type;
Linux 2.6.8 #1 SMP Tue Oct 4 13:15:08 CEST 2005 i686 GNU/Linux
Intel(R) Pentium(R) 4 CPU 2.80GHz hyperthreading
* the options given when GCC was configured/built;
GCC got from debian packages (testing)
* the
--- Comment #3 from dje at gcc dot gnu dot org 2005-10-28 17:30 ---
The misprediction causes (or at least contributes to) compute_alignments in
final.c not aligning the critical loop in longest_match. The recent changes to
bb-reorder.c moved the start of the loop from an ideal
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
Keywords||memory-hog
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-28 17:35 ---
(In reply to comment #0)
* the preprocessed file (*.i*) that triggers the bug,
Don't know how can to attach it ?
You attach it afterwards.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24573
--- Comment #2 from qijcqj8lcwka56m at jetable dot com 2005-10-28 17:40
---
Created an attachment (id=10079)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10079action=view)
gcc temporary .ii file compressed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24573
--- Comment #3 from pcarlini at suse dot de 2005-10-28 17:45 ---
Fixed for 4.0.3.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-28 17:51 ---
This works for me in 3.3.3.
How much memory do you have?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24573
--- Comment #3 from jconner at gcc dot gnu dot org 2005-10-28 17:59 ---
Subject: Bug 22153
Author: jconner
Date: Fri Oct 28 17:58:59 2005
New Revision: 105944
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=105944
Log:
PR c++/22153
* cp/parser.c (cp_parser_member_declaration):
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-28 18:01 ---
There is a couple of different bugs in the is code snipit really. Let me file
new bugs for each of them.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24568
Reduced from PR 24568:
the followin three fucntions should be equivalent:
int f(int i)
{
if (i == 0) return 0;
return i/10;
}
int f1(int i)
{
return i?i/10:0;
}
int f2(int i)
{
return i/10;
}
--
Summary: a!=0?0:a/10 is not reduced to a/10
Product: gcc
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-28 18:05 ---
(In reply to comment #1)
There is a couple of different bugs in the is code snipit really. Let me file
new bugs for each of them.
PR 24574 is the first issue which seems like it could happen in really code
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-28 18:09 ---
Fixed. Thanks Josh.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24568
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-28 18:11 ---
(In reply to comment #2)
PR 24574 is the first issue which seems like it could happen in really code
(though not as much as one thinks).
That was for the inner if.
I have to see how to reduce the outer ones.
Another reduced testcase from PR 24568:
Note this is only valid for overflow is undefined or for
unsafe_math_transformations.
nt f(int i)
{
return -((-i)/10);
}
int f2(int i)
{
return i/10;
}
--
Summary: -(-i / 10) is not foldded to i/10
Product: gcc
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-28 18:15 ---
Another issue is PR 24575:
-(-a/10) is not converted into a/10.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-28 18:18 ---
Last but not least is:
int f(int i)
{
if (i 0) return i/10;
return i/10;
}
int f2(int i)
{
return i/10;
}
Which is converted at the rtl level but not at the tree level (I think there is
a bug about this
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-28 18:19 ---
Confirmed, I am changing this into a meta-bug because there are three different
issues that this bug depends on now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-28 18:21 ---
Oh, for PR 24575 to do anything useful in this case, we need to a tree based
combiner.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-10-28 18:25
---
Right now after fixing this and PR 23777 should become fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-28 18:43
---
Here is another example which comes from PR 24568 (which really comes from
thedailywtf):
int f(int i)
{
if (i 0) return i/10+ i;
return i/10 + i;
}
int f2(int i)
{
return i/10 + i;
}
--
pinskia at gcc
--- Comment #5 from jconner at gcc dot gnu dot org 2005-10-28 18:47 ---
Subject: Bug 22153
Author: jconner
Date: Fri Oct 28 18:47:28 2005
New Revision: 105946
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=105946
Log:
Merged from mainline change #105944:
PR c++/22153
*
--- Comment #6 from jconner at gcc dot gnu dot org 2005-10-28 18:57 ---
Subject: Bug 22153
Author: jconner
Date: Fri Oct 28 18:57:33 2005
New Revision: 105947
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=105947
Log:
Merged from mainline change #105944:
PR c++/22153
*
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-28 18:58 ---
Fixed in all open branches.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from paolo dot bonzini at lu dot unisi dot ch 2005-10-28
19:16 ---
Subject: Re: [4.1 Regression] ICE in extract_insn with
altivec
On IRC it was suggested that we just need to get a version of
easy_vector_constant which does the right thing in any mode.
Yes, it
--- Comment #3 from kargl at gcc dot gnu dot org 2005-10-28 20:06 ---
Subject: Bug 24545
Author: kargl
Date: Fri Oct 28 20:05:56 2005
New Revision: 105953
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=105953
Log:
PR fortran/24545
* interface.c (gfc_match_end_interface): Fix typo
--- Comment #4 from sgk at troutmask dot apl dot washington dot edu
2005-10-28 20:07 ---
Subject: Re: gfortran bug regarding interface block with named END INTERFACE
statements
On Wed, Oct 26, 2005 at 06:54:10PM -, steven at gcc dot gnu dot org wrote:
Index: interface.c
--- Comment #2 from jason at gcc dot gnu dot org 2005-10-28 20:25 ---
This is not a bug. All member templates must be defined before an explicit
instantiation of the class. The existing standard requires an error on this
case, but a future DR will change the standard to match the g++
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-28 20:26 ---
Subject: Bug 23229
Author: pinskia
Date: Fri Oct 28 20:25:55 2005
New Revision: 105960
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=105960
Log:
2005-10-28 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #3 from sebor at roguewave dot com 2005-10-28 20:34 ---
Jason, I respectfully disagree. In bug 22263 I explained why I believe gcc is
wrong. Do you see a problem with my reasoning there? If not, you must surely
agree that this is just another example of the same bug.
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-28 20:52 ---
Subject: Bug 23229
Author: pinskia
Date: Fri Oct 28 20:52:44 2005
New Revision: 105961
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=105961
Log:
2005-10-28 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #5 from kargl at gcc dot gnu dot org 2005-10-28 20:57 ---
Subject: Bug 24545
Author: kargl
Date: Fri Oct 28 20:57:17 2005
New Revision: 105962
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=105962
Log:
PR fortran/24545
* interface.c (gfc_match_end_interface): Fix typo
--- Comment #6 from kargl at gcc dot gnu dot org 2005-10-28 20:58 ---
Fixed.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.0 |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24545
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-28 21:02 ---
Fixed in 4.0.3.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #4 from jason at gcc dot gnu dot org 2005-10-28 21:19 ---
I do disagree with your reasoning on the other bug. This DR clarifies 14.7.2:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#470
If indeed all other compilers accept this code, then perhaps the DR
A fortran main program and a fortran shared library dlopen'ed from the main
program use the same unit number to report results to two different files
(explicitely opened in the main program and in the library, see example below)
With GCC 3.x when one links with libg2c.a to produce the shared
--- Comment #2 from sven at physto dot se 2005-10-28 21:27 ---
Can we close this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16741
--- Comment #4 from hubicka at ucw dot cz 2005-10-28 21:29 ---
Subject: Re: [Bug gcov/profile/24487] [3.4/4.0/4.1 Regression] Basic block
frequencies inaccurate
--- Comment #3 from dje at gcc dot gnu dot org 2005-10-28 17:30 ---
The misprediction causes (or at least
--- Comment #5 from jason at gcc dot gnu dot org 2005-10-28 21:34 ---
Actually, I'm sympathetic to the behavior you would like to see, so I'm
reopening the bug. But I think the current behavior is clearly correct under
the DR, so I'm changing the severity to enhancement.
--
jason
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-28 21:40 ---
Why are you not linking against the shared library version of libgfortran?
What you are doing seems wrong and unsupported.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.0.3 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24511
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-28 21:43 ---
Anyways I think this is really a dup of bug 22298.
Also note the static library really needs to be compiled with -fPIC if you are
linking it in a shared library (by default it is not).
--
--- Comment #18 from pinskia at gcc dot gnu dot org 2005-10-28 21:47
---
Aldy,
Can you look into this bug?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from qijcqj8lcwka56m at jetable dot com 2005-10-28 22:13
---
(In reply to comment #3)
This works for me in 3.3.3.
How much memory do you have?
I have 248 Mb of memory
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24573
void foo(){ int a = b; }
gets you:
foo.cc: In function `void foo()':
foo.cc:1: error: `b' undeclared (first use this function)
foo.cc:1: error: (Each undeclared identifier is reported only once for each
function it appears in.)
Other informative notes are labeled note:. Because this is labelled
--- Comment #3 from iwan at irs dot phy dot nrc dot ca 2005-10-28 23:22
---
Subject: Re: Fortran I/O to same unit number in main program and in a shared
library
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-28 21:40
Why are you not linking against the shared
--- Comment #4 from jason at gcc dot gnu dot org 2005-10-28 23:38 ---
Yes, this was introduced by
2005-10-10 Mark Mitchell [EMAIL PROTECTED]
PR c++/24277
* pt.c (instantiate_decl): Call finish_static_data_member_decl for
static data members.
After this
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-28 23:44 ---
This is only a C bug now:
t.c:1: error: 'b' undeclared (first use in this function)
t.c:1: error: (Each undeclared identifier is reported only once
t.c:1: error: for each function it appears in.)
Confirmed, the C++
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |trivial
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24577
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11987
--- Comment #4 from kargl at gcc dot gnu dot org 2005-10-29 00:14 ---
Intel and PGI are wrong according to the standard. Gfortran is
doing the right thing. See section 9.4 File Connection. In
particular The external unit identified by a particular value of
a scalar-int-expr is the
Compiling the following code on MIPS emits a function call to floorf (not
floor). This is a problem when one's libc does not contain a floorf function.
void func (float *dest, float *src)
{
*dest = floor (*src);
}
Compile using 'mipsel-linux-uclibc-gcc -O2 -save-temps -c it.c'.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-29 00:52 ---
First this is a target bug and second floorf is a C99 function and really
uclibc should have it. If you want to declare this a gcc bug, you first need
to add an uclibc target and make it so it does not declare that
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23346
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24009
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-29 01:38 ---
I am looking to fix this (hopefully I can fix it).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23287
when it comes to a list directed I/O, it reports an error.
It is in the J3 spec, I think R901
read(unit=50,FMT=*,END=100)a,b,c
it will not run.
I have found that if I remove the 'unit=', then it will work, but that is a
default value, and is not according to the spec, which goes back to F77
it
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-29 01:40 ---
Related to PR 12333.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #5 from iwan at irs dot phy dot nrc dot ca 2005-10-29 01:52
---
Subject: Re: Fortran I/O to same unit number in main program and in a shared
library
I guess, it all comes down to what is a program.
If I look at section 5.5.2.3 of the 2003 Standard about common blocks,
I
--- Comment #3 from fitzsim at redhat dot com 2005-10-29 01:55 ---
I want to leave it open until we have a pure-java implementation that reads
colors from a .properties file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16741
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu
2005-10-29 02:34 ---
Subject: Re: Fortran I/O to same unit number in main program and in a shared
library
On Sat, Oct 29, 2005 at 01:52:48AM -, iwan wrote:
If I look at section 5.5.2.3 of the 2003 Standard about
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2005-10-29 02:51
---
You need to provide a complete code example. I can not reproduce an error
here.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from kargl at gcc dot gnu dot org 2005-10-29 02:52 ---
Can you add a short program with the problem? The
single read statement may not be sufficient to
reconstruct your problem.
--
kargl at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-29 03:57 ---
Hmm, pseudo_destructor_p is not being set to true.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23287
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-29 03:59 ---
The issue is this is a depedent name.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-29 04:15 ---
This problem is much harder than I though but basicially there are two issues,
we need to parse A in ~A as AT which we don't as we require a class-type.
The second issue is that we don't even get to the parsing of
101 - 181 of 181 matches
Mail list logo
