--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
06:08 ---
Here are the possible patches which could have caused this:
2005-04-01 Paolo Bonzini [EMAIL PROTECTED]
PR middle-end/19454
PR rtl-optimization/20600
...
2005-04-02 Alexandre Oliva
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
06:21 ---
After looking into this testcase and the one in PR 20742 with gdb on cc1, I
find that this is the same
bug as PR 20742.
*** This bug has been marked as a duplicate of 20742 ***
--
What
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
06:21 ---
*** Bug 20803 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
06:26 ---
Suspending as minimum/maximum operators are deprecated and are going to be
removed for 4.1.0.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
06:31 ---
*** This bug has been marked as a duplicate of 16888 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
06:31 ---
*** Bug 20214 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
06:32 ---
Copying regression markers from 20214 and the target milestone.
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-07
06:51 ---
Subject: Bug 18659
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-07 06:51:30
Modified files:
gcc:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-07
06:51 ---
Subject: Bug 18819
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-07 06:51:30
Modified files:
gcc:
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-07
06:56 ---
It only fails on mainline now.
--
What|Removed |Added
Summary|[4.0/4.1
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-07
06:57 ---
It only fails on mainline now.
--
What|Removed |Added
Summary|ACATS cdd2a02
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
07:04 ---
This was fixed on the mainline by the patch for PR 19203.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
07:06 ---
Hmm, on the mainline we reject this code:
t.cc: In function 'int main()':
t.cc:31: error: call of overloaded 'foo(int)' is ambiguous
t.cc:7: note: candidates are: some_typeA foo(const A) [with A = int]
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
07:09 ---
On the mainline we reject this code:
t.cc: In function 'int main()':
t.cc:25: error: call of overloaded 'S(int [5])' is ambiguous
t.cc:16: note: candidates are: void S(T*) [with T = int]
t.cc:19: note:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
07:24 ---
This seems to be fixed on the mainline at least for me:
gold:~gfortran -O1 t.f90
gold:~!./
./a.out ; ./a.out ; ./a.out
2.220446049250313E-016
1.626753 0.9908500
--- Additional Comments From igodard at pacbell dot net 2005-04-07 07:25
---
Flagging it as ambiguous may be correct, but I agree with Nathan that it's
wrong :-)
Ivan
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19203
--- Additional Comments From igodard at pacbell dot net 2005-04-07 07:27
---
Reporting it as ambiguous (as opposed to identifying the array) may be correct,
but I agree with Nathan that it's wrong :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15674
--
What|Removed |Added
Target Milestone|4.0.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20562
--
What|Removed |Added
Target Milestone|3.4.4 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19672
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Last reconfirmed|2004-10-29
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-07
08:22 ---
Subject: Bug 20093
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-07 08:21:36
Modified files:
gcc: ChangeLog simplify-rtx.c
Log
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-07
08:26 ---
Subject: Bug 20093
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-07 08:25:46
Modified files:
gcc:
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-04-07
08:26 ---
I can reproduce it with gcc-4.0.0 (20050406)
Interestingly, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18421#c7
does not ICE with -mO0, -mO2, -mO3!
--
What|Removed
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-04-07 08:29 ---
So, what about the proposal on #4 ?
OK with me.
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20515
--
Summary: basic_filebuf::xsgetn() fails with text mode and
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-04-07 08:35 ---
This optimization in basic_filebuf::xsgetn() causes problems on DOS based file
sytstem when ifstreams are opened in text mode (\r\n line endings) and the
user suppled buffer length exceeds
module fitness
use modinit
implicit none
contains
...
function fitness(word,totalsize)
implicit none
real:: fitness
integer :: totalsize
integer, dimension(totalsize) :: word
...
gives internal compiler error instead of showing the error in the code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
08:43 ---
Of course, I tried to reproduce this with the snip of code but cannot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20807
System type:Red Hat Linux 8.0 3.2-7
gcc Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --host=i386-redhat-linux --with-system-zlib
--enable-__cxa_atexit
Command line:
avr-gcc -mmcu=atmega128
--
What|Removed |Added
Summary|basic_filebuf::xsgetn() |[3.4/4.0/4.1 Regression]
|fails with text mode and DOS|basic_filebuf::xsgetn()
--
What|Removed |Added
Component|c |target
GCC target triplet||avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20808
--
What|Removed |Added
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20808
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
08:46 ---
Make sure that you attach the preprocessed source as requested by
http://gcc.gnu.org/bugs.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20808
--- Additional Comments From shubham_jain at da-iict dot org 2005-04-07
08:46 ---
Created an attachment (id=8552)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8552action=view)
The source code with a simple for loop causing the error.
A simple for loop when removed removes the
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
08:51 ---
Of course, the stack size is just huge (well huge for avr really).
Though with 4.0.0 and above, we remove these arrays as they are unused though
if you used them,
there will be still a bug.
Anyways this
--- Additional Comments From schwab at suse dot de 2005-04-07 09:03 ---
Needs to be fixed on 4.0 branch as well.
--
What|Removed |Added
Status|RESOLVED
--
Bug 15242 depends on bug 20648, which changed state.
Bug 20648 Summary: [4.0/4.1 regression] ICE in
cfg_layout_redirect_edge_and_branch_force
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20648
What|Old Value |New Value
attached when compiuled with -O2 shows for i386, x86_64 and ppc:
gcc -v
... 4.0.0 20050405 (prerelease) ...
gcc -O2 xx.i
xx.i: In function ‘f’:
xx.i:11: internal compiler error: in gimplify_addr_expr, at gimplify.c:3253
--
Summary: ICE in gimplify_addr_expr, at
--- Additional Comments From marcus at jet dot franken dot de 2005-04-07
09:04 ---
Created an attachment (id=8553)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8553action=view)
xx.i
testcase extracted from ncurses, compile with -O2.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
09:05 ---
*** This bug has been marked as a duplicate of 20739 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
09:05 ---
*** Bug 20809 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
What|Removed |Added
Known to fail|4.0.0 4.1.0 |4.0.0
Summary|[4.0/4.1 regression] ICE in |[4.0 regression] ICE in
--
What|Removed |Added
Status|REOPENED|ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20648
--- Additional Comments From guillemborrell at gmail dot com 2005-04-07
09:09 ---
Subject: Re: compilation crashes when a module contains
a procedure with the same name
pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-07
09:10 ---
The same patch as the one on mainline should work for 4.0.
--
What|Removed |Added
--- Additional Comments From pcarlini at suse dot de 2005-04-07 09:14
---
The problem is that the native read translates the input \r\n to
\n, returning the number of chars written,
This is a very fundamental assumption to break, which is likely to case much
more problems elsewhere,
--- Additional Comments From pcarlini at suse dot de 2005-04-07 09:14
---
The problem is that the native read translates the input \r\n to
\n, returning the number of chars written,
This is a very fundamental assumption to break, which is likely to cause much
more problems
--- Additional Comments From hp at gcc dot gnu dot org 2005-04-07 09:43
---
In response to comment #1, you can (at least as the sole cause) rule out
PR rtl-optimization/20527, as I regression-tested that before committing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20800
--
What|Removed |Added
CC||pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20806
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-04-07
10:30 ---
Created an attachment (id=8554)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8554action=view)
Revised testcase without confusing casts
This changes the testcase to not cast int* to Loc1*, but use
--- Additional Comments From pcarlini at suse dot de 2005-04-07 10:31
---
Ok, now I see the real, underlying problem: in config/io/basic_file_stdio.cc we
don't deal properly with short read, that is, we don't try to loop if the
number of read chars is n but 0. Fixing that should also
--- Additional Comments From greenrd at greenrd dot org 2005-04-07 11:06
---
gdb PR 1903 has already been filed for that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20805
--- Additional Comments From jakub at gcc dot gnu dot org 2005-04-07 11:58
---
Simplified testcase:
int *v;
int
*foo ()
{
extern int *v;
return static_castint * (v);
}
compiled with just -g on e.g. x86-64 or i386.
--
What|Removed |Added
--- Additional Comments From jakub at gcc dot gnu dot org 2005-04-07 12:13
---
int *v;
int *
foo ()
{
extern int *v;
return v;
}
The section .debug_info contains:
Compilation Unit @ 0:
Length:208
Version: 2
Abbrev Offset: 0
Pointer Size: 8
0b: Abbrev
--- Additional Comments From drow at gcc dot gnu dot org 2005-04-07 12:31
---
I have a GDB patch that will avoid the internal error. I'll dig it up.
I suppose there's room to argue that GCC's output is correct. Am I right in
thinking that the function-local extern could, in some
--- Additional Comments From dir at lanl dot gov 2005-04-07 12:44 ---
Andrew, Is there a patch for this ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20766
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-07
12:48 ---
Subject: Re: Aliasing says stores to local
memory do alias
Other than that, struct aliasing (or just removing the casts) doesn't fix the
aliasing problems - though struct aliasing doesn't
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen
dot de 2005-04-07 12:50 ---
Subject: Re: Aliasing says stores to local
memory do alias
On 7 Apr 2005, dberlin at dberlin dot org wrote:
--- Additional Comments From dberlin at gcc dot gnu dot org
--- Additional Comments From pcarlini at suse dot de 2005-04-07 13:02
---
Actually, we are not already doing that for a reason: doesn't work with pipes
(fifos), because, after the first succesful, short read, they block...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20806
Compile the following testcase with arm-elf-gcc 3.4.3 as follows:
arm-elf-gcc -c -mcpu=arm7tdmi -O2 -mthumb bitset1.cxx
With bitset1.cxx containing:
#include bitset
extern void check(void);
// 64 works, 65 doesn't
//#define N 64
#define N 65
int main( int argc, char *argv[] )
{
typedef
--- Additional Comments From jifl-bugzilla at jifvik dot org 2005-04-07
13:56 ---
Created an attachment (id=8555)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8555action=view)
Preprocessed testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20810
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
13:57 ---
(In reply to comment #4)
Andrew, Is there a patch for this ?
Not yet, I will to implement it later today after my classes are finished (at
2pm).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20766
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
14:03 ---
Jakub, do you know if this is a regression?
--
What|Removed |Added
Keywords|
--- Additional Comments From jakub at gcc dot gnu dot org 2005-04-07 14:08
---
This is caused by the big Ada patch that introduced the extra 2 ARRAY_REF
arguments. Unfortunately, I couldn't find the reason why is the last
ARRAY_REF's argument measured in aligment units and not in bytes
--- Additional Comments From jakub at gcc dot gnu dot org 2005-04-07 14:11
---
It is a regression since 3.4.x in the sense that the same testcase
was debuggable by gdb.
But the main question now is I think whether what g++ 4.0 emits is correct
or not.
--
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu
2005-04-07 14:13 ---
Subject: Re: [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))
This is caused by the big Ada patch that introduced the extra 2
ARRAY_REF arguments. Unfortunately, I
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-07
14:21 ---
Subject: Bug 20648
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-07 14:21:22
Modified files:
gcc:
--- Additional Comments From jakub at gcc dot gnu dot org 2005-04-07 14:26
---
That's wrong. The size always needs to be a multiple of the alignment.
That's fundamental.
With user defined alignment, size certainly is not necessarily a multiple of the
alignment and with the exception
--- Additional Comments From drow at gcc dot gnu dot org 2005-04-07 14:28
---
As for whether the debug information is correct:
- It would be preferable if the full declaration was the one outside the
function rather than inside, but I don't think there's anything in the
Hello,
doing some experiments with gfortran, I stumbled across the following
bug/regression with respect to g77:
consider these two files in a directory test:
$ cat test/foo.f:
subroutine foo
include 'test.h'
end
$ cat test/test.h
c just a comment
Now, compiling with g77:
--- Additional Comments From drow at false dot org 2005-04-07 14:39 ---
Subject: Re: Another debug info emitting bug
On Thu, Apr 07, 2005 at 12:31:35PM -, drow at gcc dot gnu dot org wrote:
I have a GDB patch that will avoid the internal error. I'll dig it up.
See:
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu
2005-04-07 14:41 ---
Subject: Re: [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))
With user defined alignment, size certainly is not necessarily a
multiple of the alignment and with the
--- Additional Comments From schwab at suse dot de 2005-04-07 14:44 ---
Really fixed now.
--
What|Removed |Added
Status|NEW |RESOLVED
--
Bug 15242 depends on bug 20648, which changed state.
Bug 20648 Summary: [4.0 regression] ICE in
cfg_layout_redirect_edge_and_branch_force
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20648
What|Old Value |New Value
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-07
16:43 ---
Subject: Re: Aliasing says stores to local
memory do alias
Other than that, struct aliasing (or just removing the casts) doesn't fix
the
aliasing problems - though struct aliasing
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
16:45 ---
Confirmed.
--
What|Removed |Added
OtherBugsDependingO||19292
--- Additional Comments From ericw at evcohs dot com 2005-04-07 16:47
---
According to this related thread:
http://gcc.gnu.org/ml/gcc/2005-03/msg01079.html
There is a patch on the MinGW project here:
http://sourceforge.net/tracker/?func=detailatid=102435aid=1053052group_id=2435
This
--- Additional Comments From ericw at evcohs dot com 2005-04-07 16:50
---
Created an attachment (id=8556)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8556action=view)
Patch from MinGW project that fixes the problem on Win2k,XP
This patch is from the MinGW project, at this bug
--
What|Removed |Added
Keywords||patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20594
--- Additional Comments From hjl at lucon dot org 2005-04-07 17:39 ---
Another patch is needed to fully fix the bug:
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00787.html
BTW, special charactor isn't supported by libtool:
--- Additional Comments From rth at gcc dot gnu dot org 2005-04-07 17:52
---
For the record, this has come up on the lists before in some slightly other
context and Mark has advocated (1). I'm of a mind to agree.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20794
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu
2005-04-07 17:54 ---
Subject: Re: [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))
For the record, this has come up on the lists before in some slightly
other context and Mark has advocated
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-07
18:00 ---
Yes, I still think that we ought to declare this invalid code.
If a particular front end (e.g., Ada) wants to adjust the types of the array
elements, etc., that's its business -- but the C/C++ front-ends
The problem is best demonstrated by a code snippet. The following snippet
shows it as a wrong-code, but if we remove the first function template test
we get a rejects-valid case:
#include iostream
#include ostream
struct B1 { int foo; };
struct B2 { double foo; };
struct D: B1, B2 { };
template
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu
2005-04-07 18:03 ---
Subject: Re: [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))
And the middle end should be able to expect that the size of the
elements is at least as large as their
--- Additional Comments From mark at codesourcery dot com 2005-04-07 18:08
---
Subject: Re: [4.0/4.1 Regression] Miscompilation with
__attribute ((aligned))
kenner at vlsi1 dot ultra dot nyu dot edu wrote:
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu
--- Additional Comments From SWElef at post dot sk 2005-04-07 18:12 ---
I forgot to write that I used gcc-3.4.2-mingw, gcc-3.4.3-cygwin and
gcc-4.0.0-experimental-20050130 and the results were the same, i.e. buggy.
Vladimir Marko
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
18:14 ---
Just a note as I don't know if this is not a bug or not but ICC 8.1 also has
the same behavior as GCC.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
19:07 ---
Fixed.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
19:08 ---
I am testing a patch right now.
--
What|Removed |Added
AssignedTo|unassigned at gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
19:29 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00806.html.
--
What|Removed |Added
-20050407/bin/gcc -m64 -c 930106-1.c
930106-1.c: In function f:
930106-1.c:20: internal compiler error: in gen_reg_rtx, at emit-rtl.c:778
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions
--- Additional Comments From twilson at ems dot jsc dot nasa dot gov
2005-04-07 20:14 ---
I agree with both Federico Carminati and Alfredo Ferrari at CERN. The compiler
is not usable and the impact is serious for thousands of existing fortran
programs. Please fix it soon.
--
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Keywords|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
20:50 ---
-m64 -mcpu=rs64a is enough to reproduce the bug.
--
What|Removed |Added
--- Additional Comments From kreckel at ginac dot de 2005-04-07 20:51
---
(In reply to comment #11)
I think we need more careful analysis and tracking of both C99, C++ and
LIA-3.
Apart from looking at standards, we could also try to use our brains, right? It
must be possible to
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
20:51 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
20:52 ---
Fixed checked into the mainline for 4.1.0.
--
What|Removed |Added
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-07
20:58 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
1 - 100 of 147 matches
Mail list logo
