--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-02 20:39 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2005-11-02
20:36 ---
Created an attachment (id=10114)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10114&action=view)
Test case for this bug
Test case added.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24643
gfortran issues an "Unclassifiable statement" error when trying
to compile a statement with concatenation of substrings of
character variables.
--
Summary: Unclassifiable statement on character substring
concatenation
Product: gcc
Version: 4.1
--- Comment #2 from uweigand at gcc dot gnu dot org 2005-11-02 20:27
---
Clearly a backend bug. Working on it ...
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-02 20:01 ---
This does not warn for me on the mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20021
--- Comment #4 from h dot b dot furuseth at usit dot uio dot no 2005-11-02
19:52 ---
I think I'd appreciate that warning when writing portable code:
The warning can be useful if the 1 is replaced with a macro
which may or may not expand to 1, or an enum defined in an #ifdef,
or an impl
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-02 19:43 ---
This is related to PR 24481.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsT
--- Comment #16 from dnovillo at gcc dot gnu dot org 2005-11-02 19:40
---
testing patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24627
The following code should produce random numbers between 0..2^5-1:
import java.math.BigInteger;
import java.security.SecureRandom;
class RndTest {
public static void main(String[] args) {
SecureRandom rnd = new SecureRandom();
for (int i = 0; i < 10; i++)
System.out.print(
$ cat test_cmt.f90
program test_comments
real :: &
&
a
end program test_comments
$ This is a valid code (i think) checked against Lahey's syntax checker,
getting rejected by gfortran.
$ gfortran test_cmt.f90
In file test_cmt.f90:2
real :: &
1
Error: Syntax e
--- Comment #2 from janis at gcc dot gnu dot org 2005-11-02 19:18 ---
A regression hunt using a cross compiler identified the following patch:
r105306 | rth | 2005-10-12 16:29:35 + (Wed, 12 Oct 2005) | 3 lines
PR rtl-opt/23324
* cfgexpand.c (add_alias_set_conflicts)
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-02 19:17 ---
Some more, this time closed ones. There are many more.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
$ cat test.f90
10: a=10
end
$ gfortran test.f90
In file ice.f90:1
20:a=10
1
Warning: Ignoring bad statement label at (1)
ice.f90: In function MAIN__:
ice.f90:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See htt
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-02 19:01 ---
Adding Jeff Law and Diego so they know what the bug numbers are.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-02 19:00 ---
There are at least 19 bugs related to the uninit warnings.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||5035, 10138, 16865, 17506,
|
To get a better feeling for the issues which have been reported, this meta-bug
should get the better feeling for them.
--
Summary: [meta-bug] bug to track all uninit variable issues
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: d
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-11-02 18:36
---
Fixed in 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-11-02 18:32
---
Subject: Bug 24569
Author: mmitchel
Date: Wed Nov 2 18:32:09 2005
New Revision: 106393
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106393
Log:
PR c++/24569
* pt.c (instantiate_decl): Us
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-11-02 18:30
---
Subject: Bug 24569
Author: mmitchel
Date: Wed Nov 2 18:30:26 2005
New Revision: 106392
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106392
Log:
PR c++/24569
* pt.c (instantiate_decl): Us
--- Comment #2 from kargl at gcc dot gnu dot org 2005-11-02 18:27 ---
This has bugged me also. For a patch, see
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00122.html
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from rth at gcc dot gnu dot org 2005-11-02 18:20 ---
Subject: Bug 24178
Author: rth
Date: Wed Nov 2 18:20:07 2005
New Revision: 106388
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106388
Log:
PR target/24178
* config/alpha/alpha.c (get_aligned_
--- Comment #9 from rrr6399 at futuretek dot com 2005-11-02 18:17 ---
I imagine code from g95 could be leveraged to support this feature couldn't it?
This is a really important feature, especially in corporate environments where
there is usually mix of big-endian and little-endian machi
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2005-11-02 17:54
---
> Hmm, I would almost want to go on a limb and say this was caused by the patch
> for PR 21166. Can you try to revert that patch and try the mainline compiler?
Of course that's it. Thanks for spotting this!
-
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-02 17:41 ---
Hmm, I would almost want to go on a limb and say this was caused by the patch
for PR 21166. Can you try to revert that patch and try the mainline compiler?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24462
--- Comment #7 from elizabeth dot brosch at thomson dot com 2005-11-02
17:21 ---
Subject: RE: Make Bootstrap fails on AIX 5.2 ML6
I agree. I realized that this was unnecessary. Thanks for the reply.
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-30 17:17
---
Wh
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-02 17:16
---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-02 17:16
---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-11-02 17:16
---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from janis at gcc dot gnu dot org 2005-11-02 17:15 ---
A regression hunt on powerpc-linux identified this patch:
r100793 | rth | 2005-06-09 07:43:40 + (Thu, 09 Jun 2005) | 38 lines
PR tree-opt/20610
--
janis at gcc dot gnu dot org changed:
Wha
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-02 17:02
---
A link to the changes (so I can be a little lazy):
http://gcc.gnu.org/viewcvs?view=rev&rev=101841
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24627
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-02 16:39
---
This is as far as I can reduce it, -O1:
typedef union {
unsigned a;
} l_fp;
int main(void)
{
l_fp work;
unsigned workUl_fXl_uf = 0x;
int ndec = 10;
do {
ndec--;
work.a = 0;
work.a = 0;
Jv_FindClass throws a ClassNotFoundException in case the requested class cannot
be resolved (regardless of whether the bytecode missing or a further dependency
cannot be resolved).
This causes problems because in case of serious bytecode errors (eg. the class
of a field is missing) where a NoClass
--- Comment #5 from uweigand at gcc dot gnu dot org 2005-11-02 16:32
---
Confirmed. Looks like a backend problem, I'm working on it.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from paolo at gcc dot gnu dot org 2005-11-02 16:24 ---
Subject: Bug 23425
Author: paolo
Date: Wed Nov 2 10:27:54 2005
New Revision: 106379
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106379
Log:
2005-11-02 Thomas Kho <[EMAIL PROTECTED]>
PR libstdc++
public class Foo {
static MissingClass STATIC_MIA;
}
public class Foo2{
MissingClass NONSTATIC_MIA;
}
Foo and Foo2 should pass the verifier if the bytecode for MissingClass is
absent.
--
Summary: static and non-static declarations of missing type do
not pas
--- Comment #6 from uweigand at gcc dot gnu dot org 2005-11-02 16:22
---
Tested patch in:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00113.html
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-02 16:12
---
(In reply to comment #12)
> Here is another more reduced testcase (still at -O1 -fno-tree-sra):
That testcase is invalid, the one which is valid:
ypedef struct {
unsigned a;
} l_fp;
void dolfptoa(short ndec)
{
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-02 16:03
---
Here is another more reduced testcase (still at -O1 -fno-tree-sra):
typedef struct {
unsigned a;
} l_fp;
void dolfptoa(short ndec)
{
l_fp work;
unsigned workUl_fXl_uf;
work.a = 0x535f3d8;
while (ndec > 0)
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-02 15:53
---
The following fails with -O1 -fno-tree-sra.
typedef struct {
struct {unsigned Xl_ui;} Ul_i;
struct {unsigned Xl_uf;} Ul_f;
} l_fp;
void dolfptoa(short ndec)
{
l_fp work;
work.Ul_f.Xl_uf = 0x535f3d8;
while
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-02 15:47
---
Here is a further reduced testase:
typedef struct {
union {unsigned Xl_ui;} Ul_i;
union {unsigned Xl_uf;} Ul_f;
} l_fp;
void dolfptoa(short ndec)
{
l_fp work;
work.Ul_f.Xl_uf = 0x535f3d8;
while (ndec > 0)
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-02 15:19 ---
Are you sure that there are no relocations and that it is zero because of them?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24634
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-02 15:14 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-02 15:05 ---
And works in 4.0.3 but not in 3.4.5 and 3.4.0.
Closing as fixed for 4.0.3 since this was not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-02 14:59 ---
Confirmed, this is more of a front-end issue than a library issue. As the
front-end emits a call to _gfortran_stop_numeric in both the STOP cases.
--
pinskia at gcc dot gnu dot org changed:
What|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-02 14:55 ---
I cannot reproduce this with the compiler version you have.
GNU C version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)
(x86_64-linux-gnu)
--
pinskia at gcc dot gnu dot org changed:
What|Rem
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-02 14:51 ---
I cannot reproduce this on 4.0.1 or CVS HEAD of 4.0 (20050919), nor on 4.1.0.
What optimization options did you use?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #15 from hubicka at ucw dot cz 2005-11-02 14:32 ---
Subject: Re: [4.1 Regression] Slowdown of the bresenham line drawing by
roughly 20%
>
>
> --- Comment #13 from law at redhat dot com 2005-10-31 23:36 ---
> Subject: Re: [4.1 Regression] Slowdown of the
>
>
>
> --- Comment #13 from law at redhat dot com 2005-10-31 23:36 ---
> Subject: Re: [4.1 Regression] Slowdown of the
> bresenham line drawing by roughly 20%
>
> On Mon, 2005-10-31 at 23:25 +, hubicka at ucw dot cz wrote:
>
> > See comment #5. The fact that we ended up wi
Hi,
as it has bothered me for quite some time, I finally
decided to report. The program
program gfcbug29
stop
end
when compiled with g77, executes and terminates without any message.
*Only* when a stop code is present, as in
stop 0
it (the g77 runtime) says so. However,
--- Comment #2 from jakub at gcc dot gnu dot org 2005-11-02 14:03 ---
Fixed on the branch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #1 from jakub at gcc dot gnu dot org 2005-11-02 13:59 ---
Subject: Bug 24613
Author: jakub
Date: Wed Nov 2 13:59:00 2005
New Revision: 106383
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106383
Log:
PR c++/24613
* c-parser.c (c_parser_pragma): Diag
/*
* Summary:
* Wrong statement reordering
* Description:
* If you run this program, it will produce an output of 1.
* The reason is that the assignment V1=0 which should be
* executed before the call to cl_throw() is moved after
* this call, and hence when cl_throw(
--- Comment #2 from anglade at gmail dot com 2005-11-02 13:28 ---
(In reply to comment #1)
> Full testcase:
> module abc
> contains
> function abc()
> i=1
> end function
> end module
>
>
> There is actually two problems here, the first is the message about the
> conflicts is not very c
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-02 13:15 ---
Full testcase:
module abc
contains
function abc()
i=1
end function
end module
There is actually two problems here, the first is the message about the
conflicts is not very clear. The second issue is that the error
--- Comment #6 from ed at eh3 dot com 2005-11-02 13:12 ---
Hi jvdelisle, I'm not sure if it qualifies as "high priority" but it is one
of the few (only?) gfortran bugs that we've encountered with the MITgcm fluid
flow and transport model (http://mitgcm.org). If it helps, I'll be happy
We are using a cross compiler for 64 bit Linux on MIPS yosemite. When we
compile c sources with command: mips64-linux-gnu-gcc -c -gdwarf-2 -mabi=64
xxx.c then the value of atribute in dwarf2 info : DW_AT_high_pc and
DW_AT_low_pc is 0 what is surely wrong
for mips64-linux-gnu-gcc -c -gdwarf-2 -mabi
--- Comment #4 from tobi at gcc dot gnu dot org 2005-11-02 12:37 ---
I was curious, and tried below patch, changing .EQV. to .NEQV. in the testcase,
and still we don't get the "right" result, since our logical type is a real
logical, in that only the lowest bit is considered. I did some
--- Comment #8 from alexander_herrmann at yahoo dot com dot au 2005-11-02
11:29 ---
I guessed somebody found it before but searching the db I couldn'n find it.
Anyway shouldn't we make it than dependend or blocking Bug
#tree-optimization/21513
As the funktion while C correct will never
--- Comment #3 from thebohemian at gmx dot net 2005-11-02 11:09 ---
Created an attachment (id=10113)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10113&action=view)
lazy linker test setup
This is a newer version of the test for class linking. The change is that the
actual tests a
"MODULE attribute conflicts with PROCEDURE attribute"
this error message is not accurate enough.
The conflicting attribute should be mentionned.
For instance in:
module abc
contain
function abc()
The conflicting attributes is the name of the module and the name of the
function.
this is va
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23425
--- Comment #5 from pcarlini at suse dot de 2005-11-02 10:29 ---
Fixed for 4.1.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #3 from rearnsha at gcc dot gnu dot org 2005-11-02 10:13
---
> ../.././gcc/config/arm/lib1funcs.asm:731: Error: no such instruction: `moveq
> pc,lr'
This just shows that you aren't picking up an ARM assembler. Have you
installed GAS correctly? and does the compiler know h
--- Comment #2 from giovannibajo at libero dot it 2005-11-02 09:20 ---
Template parameters can't be used in friend declarations (nor in any elaborated
type specifier construct).
--
giovannibajo at libero dot it changed:
What|Removed |Added
--
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 #1 from jakub at gcc dot gnu dot org 2005-11-02 08:23 ---
That testcase is IMHO invalid (see
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00099.html
), but
void
foo (void)
{
int i;
#pragma omp parallel sections shared (i)
{
#pragma omp section
{
i = 0;
++i
--- Comment #5 from rth at gcc dot gnu dot org 2005-11-02 08:09 ---
And there is nothing Alpha specific about this. Any target which passes
structures in registers can show it. For instance, ia64:
f1:
.prologue
.body
.mmi
st2 [r12] = r32
nop 0
--- Comment #4 from rth at gcc dot gnu dot org 2005-11-02 08:06 ---
Still present in 4.1.
As a guess, we're creating a BLKmode register (because alignof(struct s1)
is less than alignof(HImode)), and assign_parm_setup_block forces the data
into the stack. It's possible this can be bypas
101 - 183 of 183 matches
Mail list logo
