I suggest to look at the following situation.
[EMAIL PROTECTED]:~/Projekte/GNU/GCC/erzeugt/Test-4.2.2>
~/Projekte/GNU/GCC/Quellen/4.2.2/configure
creating cache ./config.cache
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking bui
--- Comment #9 from tbm at cyrius dot com 2007-10-20 06:10 ---
(In reply to comment #8)
> Would you do the following for the failing assert?
> p debug_rtx (insn)
> p debug_rtx (i1)
> p debug_rtx (substed)
Breakpoint 3, delete_output_reload (insn=0x2ab2d757c140, j=1,
last_reload_reg=21)
--- Comment #6 from patchapp at dberlin dot org 2007-10-20 05:45 ---
Subject: Bug number PR31306
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/2007-10/msg01207.html
--
http://gcc.gnu.org/bugzilla/sh
The configuration option "--enable-languages" is explained in the following
documents.
- "Installing GCC: Configuration"
http://gcc.gnu.org/install/configure.html
- "Installing all the GCC compilers while building LFS" by Randy McMurchy
http://www.linuxfromscratch.org/hints/downloads/files/all
--- Comment #5 from patchapp at dberlin dot org 2007-10-20 04:24 ---
Subject: Bug number PR 33818
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/2007-10/msg01188.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #34 from patchapp at dberlin dot org 2007-10-20 04:22 ---
Subject: Bug number PR31608
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/2007-10/msg01072.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #4 from patchapp at dberlin dot org 2007-10-20 04:21 ---
Subject: Bug number PR31217
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/2007-10/msg01043.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #24 from patchapp at dberlin dot org 2007-10-20 04:21 ---
Subject: Bug number PR32921
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/2007-10/msg01036.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #1 from jakub at gcc dot gnu dot org 2007-10-20 04:08 ---
*** This bug has been marked as a duplicate of 33439 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from jakub at gcc dot gnu dot org 2007-10-20 04:08 ---
*** Bug 33718 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from alexandre dot nunes at gmail dot com 2007-10-20 01:49
---
Created an attachment (id=14374)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14374&action=view)
A complete testcase.
I compiled with gcc -ggdb3 file.c -o file, no optimization flags.
--
http://gc
I have two structs (the unions are there for the sake of testing, it still
behaves the same without them):
#define ATTRIBUTE_PACKED_STRUCT __attribute__((gcc_struct,packed))
#include
#include
typedef union ATTRIBUTE_PACKED_STRUCT
{
struct ATTRIBUTE_PACKED_STRUCT {
uint8_t a:1,
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-10-20 00:18 ---
Try this one:
/* { dg-do run } */
/* { dg-options "-O3 -fipa-cp" } */
int k;
void f1 (int a, int b)
{
if (a)
{
int c;
goto d;
do {
k = 1;
d:
c = b--;
}while (c);
}
e
--- Comment #10 from amodra at bigpond dot net dot au 2007-10-20 00:08
---
Prior to my patch:
.L.main1:
mflr 0
mr 12,1
std 0,16(1)
lis 0,0x
ori 0,0,4656
stdux 1,1,0
mfvrsave 0
stw 0,-4(12)
so we store vrsave at frame_t
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-10-20 00:05 ---
(In reply to comment #3)
> A regression hunt on powerpc-linux identified this patch:
HEHEHEHEHEHEHE. Seriously this is funny.
Anyways try changing the code to be (which will not invoke my removal of the
"optimizati
--- Comment #4 from bangerth at dealii dot org 2007-10-19 23:54 ---
This is the shortest I can come up with:
--
template
struct __attribute__((visibility("default"))) List {};
int bar(List args);
bool test(const List &);
int i = bar(List());
bool test(const List &
--- Comment #3 from amodra at bigpond dot net dot au 2007-10-19 23:51
---
*** This bug has been marked as a duplicate of 33812 ***
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
-
--- Comment #9 from amodra at bigpond dot net dot au 2007-10-19 23:51
---
*** Bug 33806 has been marked as a duplicate of this bug. ***
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
--
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net
|dot org
--- Comment #8 from amodra at bigpond dot net dot au 2007-10-19 23:48
---
I'm building a current powerpc64 compiler at the moment to verify, but I think
this is because rs6000_emit_epilogue is now generating mems with address
sp+offset where offset is too large. Prior to my patch we re
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-10-19 23:48 ---
(In reply to comment #3)
> Another, smaller, issue is that in case of ICEs on invalid should be
> more clear from the PR whether it
> happens only in development builds, or not: the latter are definitely less
> serio
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-19 23:41 ---
Variable tracking is new for 4.0.0 so this is a regression from 3.4.x and it
ICEd in 4.0.2.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
Compile the following code at -O -g -mstrict-align and you get an ICE in
set_variable_part:
void ProjectOverlay(const float localTextureAxis[2], char *lump) {
const void *d = &localTextureAxis;
int size = sizeof(float)*8 ;
__builtin_memcpy( &lump[ 0 ], d, size );
}
- CUT --
--- Comment #3 from janis at gcc dot gnu dot org 2007-10-19 23:32 ---
Created an attachment (id=14373)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14373&action=view)
smaller testcase, thanks to delta
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33620
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-10-19 23:21
---
I see that this ICE has been fixed along the way. For the test case in comment
#2 we still get three error messages, but this is because we do not disable
resolve.c and more than one code path gets taken. There
--- Comment #3 from janis at gcc dot gnu dot org 2007-10-19 23:00 ---
The failure also shows up on powerpc-linux, where a regression hunt identified:
http://gcc.gnu.org/viewcvs?view=rev&rev=124403
r124403 | hubicka | 2007-05-04 00:40:20 + (Fri, 04 May 2007)
--
janis at
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-19
22:16 ---
Subject: Re: [4.2 Regression] ICE in delete_output_reload, at reload1.c:7926
> #1 0x00601eac in delete_output_reload (insn=0x2b78f71e4140, j=1,
> last_reload_reg=21)
> at gcc-4.2/gcc/reload1.c
--- Comment #16 from janis at gcc dot gnu dot org 2007-10-19 22:14 ---
A regression hunt on powerpc-linux using the testcase from comment #3
identified this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=119502
r119502 | dberlin | 2006-12-04 19:07:05 + (Mon, 04 Dec 2006)
--- Comment #23 from hjl at lucon dot org 2007-10-19 22:13 ---
Gcc 4.3 revision 129493 makes 437.leslie3d 25% faster than revision 129372 on
Intel Core 2 Duo 64bit. But it is still 13% slower than gcc 4.1 Red Hat.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-10-19 22:01
---
Not worth the effort.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from spop at gcc dot gnu dot org 2007-10-19 21:54 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to
optimize code
Just looking again to this old bug...
The problem with VRP/DOM is that they just state equalities, and then
they apply the subst
--- Comment #7 from tbm at cyrius dot com 2007-10-19 21:36 ---
Breakpoint 1, fancy_abort (file=0x7c02a8 "gcc-4.2/gcc/reload1.c", line=7932,
function=0x7c01f0 "delete_output_reload") at gcc-4.2/gcc/diagnostic.c:640
640 {
(gdb) where
#0 fancy_abort (file=0x7c02a8 "gcc-4.2/gcc/relo
--- Comment #6 from tbm at cyrius dot com 2007-10-19 21:33 ---
Here's the reduced testcase from delta. I can try to reduce it further
manually
tomorrow.
typedef unsigned long int ulong;
typedef unsigned int uint;
typedef unsigned char uchar;
typedef unsigned long long int ulonglong;
t
--- Comment #5 from tbm at gcc dot gnu dot org 2007-10-19 21:31 ---
Confirmed.
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from tbm at cyrius dot com 2007-10-19 21:29 ---
Adding Dave.
--
tbm at cyrius dot com changed:
What|Removed |Added
CC|
unexpected failures13
# of unexpected successes 2
# of expected failures 166
# of untested testcases 35
# of unsupported tests 419
/opt/gcc/darwin_buildw/gcc/xgcc version 4.3.0 20071019 (experimental) (GCC)
This can be compared to
http://gcc.gnu.org/ml/gcc
--- Comment #4 from burnus at gcc dot gnu dot org 2007-10-19 21:16 ---
I'm not completely sure which bug is triggered that, but the error occurs for
the expression
character(len(str)) :: UpperCase
"str" is a dummy (of the interface function UpperCase) and despite being a
dummy it
--- Comment #10 from tbm at cyrius dot com 2007-10-19 21:12 ---
I forgot to mention that this is on Linux (Debian).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29209
--- Comment #9 from tbm at cyrius dot com 2007-10-19 21:10 ---
(In reply to comment #8)
> Whether or not an ICE occurs depends to some extent
> on checking being enabled. With checking enabled, I see this on 4.1
> and the trunk.
>
> The ICE is here:
>
> result = expand_expr
--- Comment #2 from Markus dot Elfring at web dot de 2007-10-19 20:54
---
By the way: There is another report on this specific issue with the topic "make
check on -CURRENT in lang/gnat-gcc41" by Petr Holub.
http://groups.google.de/group/mailing.freebsd.ports/msg/0aeb2c869f508d92
--
struct R1 {};
struct R2 : R1 {};
struct R3 : R1 {};
struct R4 : R2, R3 {};
struct A { virtual R1& foo(); };
struct B : virtual A { R2& foo(); };
struct C : virtual A { R3& foo(); };
struct D : B, C { R4& foo(); }; // should be rejected
R4 contains two subobjects of type R1. When D::foo is inv
--- Comment #1 from Markus dot Elfring at web dot de 2007-10-19 20:41
---
I hope that the rest of my test result is fine, isn't it?
=== gcc Summary ===
# of expected passes42098
# of expected failures 127
# of unresolved testcases 1
# of unte
--- Comment #3 from pcarlini at suse dot de 2007-10-19 20:27 ---
In fact at some point I'd like to open a discussion about what we consider a
*regression*. I mean, *regression* means to me, roughly, "something used to
work and now all of a sudden doesn't work anymore, we must quickly fix
--
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 #2 from janis at gcc dot gnu dot org 2007-10-19 20:07 ---
This isn't a regression. The error is reported with a compiler from 20070210,
the day after support for variadic templates was added.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31993
What is wrong with the following test after the current release was build on my
openSUSE 10.3 system?
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using
/home/el
--- Comment #3 from janis at gcc dot gnu dot org 2007-10-19 19:52 ---
A regression hunt on powerpc-linux identified this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=124353
r124353 | pinskia | 2007-05-02 17:47:06 + (Wed, 02 May 2007)
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-10-19 19:27 ---
(In reply to comment #1)
> This isn't a regression, variadic templates were added on 20070209 and this
> fails with a compiler from 20070210.
Well the ICE itself is a regression.
So the regression marker is used for
--- Comment #1 from janis at gcc dot gnu dot org 2007-10-19 19:24 ---
This isn't a regression, variadic templates were added on 20070209 and this
fails with a compiler from 20070210.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32252
--- Comment #5 from spop at gcc dot gnu dot org 2007-10-19 19:03 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #24 from spop at gcc dot gnu dot org 2007-10-19 19:03 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #12 from spop at gcc dot gnu dot org 2007-10-19 19:02 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #23 from spop at gcc dot gnu dot org 2007-10-19 19:02 ---
Subject: Bug 24309
Author: spop
Date: Fri Oct 19 19:01:58 2007
New Revision: 129494
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129494
Log:
2007-10-19 Sebastian Pop <[EMAIL PROTECTED]>
PR tree-op
--- Comment #11 from spop at gcc dot gnu dot org 2007-10-19 19:02 ---
Subject: Bug 23820
Author: spop
Date: Fri Oct 19 19:01:58 2007
New Revision: 129494
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129494
Log:
2007-10-19 Sebastian Pop <[EMAIL PROTECTED]>
PR tree-op
--- Comment #4 from spop at gcc dot gnu dot org 2007-10-19 19:02 ---
Subject: Bug 33766
Author: spop
Date: Fri Oct 19 19:01:58 2007
New Revision: 129494
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129494
Log:
2007-10-19 Sebastian Pop <[EMAIL PROTECTED]>
PR tree-opt
> What is the recommended procedure to regenerate them?
Not sure there is one.
> Shouldn't they be regenerated and committed in CVS?
No, because that changes the base requirements for all those packages.
DJ Delorie wrote:
I am on Fedora 7 with autoconf 2.61 with a checkout from
yesterday off the trunk. So I shouldn't have see it based
upon that requirement. What else could it be?
Did you re-generate all the configure's from all the configure.ac's?
The ones in CVS are all built with 2.59.
> I am on Fedora 7 with autoconf 2.61 with a checkout from
> yesterday off the trunk. So I shouldn't have see it based
> upon that requirement. What else could it be?
Did you re-generate all the configure's from all the configure.ac's?
The ones in CVS are all built with 2.59.
When this test is compiled and run using -O2 with gcc 4.2 and with mainline, it
fails (tested on i686-pc-linux-gnu). It succeeds with 4.1.
class s
{
public:
s(long long aa) : a(aa), i1(0) { }
long long id() const { return (this->a << 16) >> 16; }
bool operator< (s sv) { return this->a < sv.
DJ Delorie wrote:
http://sourceware.org/ml/newlib/2006/msg00472.html
Shouldn't this patch already be in the top level
gcc/Makefile.in?
The right fix is to use autoconf 2.60 or later.
I am on Fedora 7 with autoconf 2.61 with a checkout from
yesterday off the trunk. So I shouldn't hav
--- Comment #7 from ubizjak at gmail dot com 2007-10-19 17:53 ---
(In reply to comment #6)
> It is little bit sick, but what about implying -mfpmath=sse when
> -ftree-vectorize is used and SSE is available?
Then you will hit Core2 Duo, that shows the opposite in 32bit and 64bit mode:
-
--- Comment #3 from janis at gcc dot gnu dot org 2007-10-19 17:48 ---
I can reproduce this on powerpc64-linux with a compiler from 20070630 but not
with anything after 30070731; can anyone else still reproduce the failure, or
has it been fixed?
--
http://gcc.gnu.org/bugzilla/show_bu
> http://sourceware.org/ml/newlib/2006/msg00472.html
>
> Shouldn't this patch already be in the top level
> gcc/Makefile.in?
The right fix is to use autoconf 2.60 or later.
The patch you link to requires GNU make, and thus was rejected.
--- Comment #7 from paolo at gcc dot gnu dot org 2007-10-19 17:36 ---
Subject: Bug 33815
Author: paolo
Date: Fri Oct 19 17:36:03 2007
New Revision: 129493
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129493
Log:
2007-10-19 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
Hi,
I switched my testing from gcc 4.2.x to the svn
trunk so I could submit things. I ran into the
problem reported and fixed here:
http://sourceware.org/ml/newlib/2006/msg00472.html
Shouldn't this patch already be in the top level
gcc/Makefile.in?
--joel
--- Comment #3 from burnus at gcc dot gnu dot org 2007-10-19 17:09 ---
> http://gcc.gnu.org/wiki/GFortranBinariesWindows instructs me to "report any
> bugs to the [EMAIL PROTECTED] mailing-list".
>
> If I posted in the wrong place, I apologize.
Regarding GDB: You should either contact
--- Comment #4 from janis at gcc dot gnu dot org 2007-10-19 16:42 ---
A regression hunt on powerpc-linux identified the following patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=126198
r126198 | rguenth | 2007-07-02 11:53:08 + (Mon, 02 Jul 2007)
This results in the ICE repo
--- Comment #2 from janis at gcc dot gnu dot org 2007-10-19 16:39 ---
The error also occurs on powerpc64-linux with -m64, where a regression hunt
identified the following patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=128488
r128488 | jason | 2007-09-14 06:07:25 + (Fri, 14
--- Comment #6 from dominiq at lps dot ens dot fr 2007-10-19 16:39 ---
See comment#2 of PR33806. I did not tested the gcc side.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33812
--- Comment #2 from janis at gcc dot gnu dot org 2007-10-19 16:36 ---
The testcase also fails on powerpc-linux, where a regression hunt identified
the following patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=128701
r128701 | aaw | 2007-09-23 20:05:40 + (Sun, 23 Sep 2007)
--- Comment #2 from dominiq at lps dot ens dot fr 2007-10-19 16:36 ---
I have reverted the changes made in revision 129400 and the reported errors
disappeared. Hence added Alan Modra to the cc list.
--
dominiq at lps dot ens dot fr changed:
What|Removed
--- Comment #4 from janis at gcc dot gnu dot org 2007-10-19 16:34 ---
A regression hunt using the testcase added for comment #2 on powerpc-linux with
"-O2 -fstack-protector" identified the following patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=121780
r121780 | hubicka | 2007-
--- Comment #4 from janis at gcc dot gnu dot org 2007-10-19 16:31 ---
A regression hunt for the first testcase on powerpc-linux identified the
following patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=120649
r120649 | ian | 2007-01-10 21:07:38 + (Wed, 10 Jan 2007)
--
jan
--- Comment #22 from rguenth at gcc dot gnu dot org 2007-10-19 16:28
---
Actually, the fix for PR33816 might have fixed this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-19 16:27 ---
This is now fixed. Still the world waits for gimplifying after the FE finished
all of its business.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from michael dot a dot richmond at nasa dot gov 2007-10-19
15:52 ---
http://gcc.gnu.org/wiki/GFortranBinariesWindows instructs me to "report any
bugs to the [EMAIL PROTECTED] mailing-list".
If I posted in the wrong place, I apologize.
--
http://gcc.gnu.org/bugzilla/
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-10-19 15:36
---
Subject: Bug 32921
Author: rguenth
Date: Fri Oct 19 15:36:05 2007
New Revision: 129491
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129491
Log:
2007-10-19 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-19 15:36 ---
Subject: Bug 33816
Author: rguenth
Date: Fri Oct 19 15:36:05 2007
New Revision: 129491
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129491
Log:
2007-10-19 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-19 15:32 ---
gdb is a different project and we don't support binary packages anyways. You
should report this bug to the person who makes the binary package.
--
pinskia at gcc dot gnu dot org changed:
What|Rem
--- Comment #2 from cbas25 at strath dot ac dot uk 2007-10-19 15:25 ---
Thank you for the prompt response
I have taken your suggestion about including "-v" in the command line.
I have compiled the source of the program (strauss.f) with both the g77 nd
gfortran compilers. Incidently the
--- Comment #3 from burnus at gcc dot gnu dot org 2007-10-19 15:15 ---
Slightly further reduced test:
subroutine ExportZMX(lu)
implicit none
integer :: lu
interface
function UpperCase(str)
character(*),intent(in) :: str
character(len(str)) :: UpperCase ! Reject
--- Comment #2 from dominiq at lps dot ens dot fr 2007-10-19 15:12 ---
It is not in gcc version 4.3.0 20070713.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33818
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirme
--- Comment #1 from dominiq at lps dot ens dot fr 2007-10-19 15:07 ---
The bug is not present in 4.2.2, and appeared before revision 129038.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33818
Reduced from http://gcc.gnu.org/ml/fortran/2007-10/msg00280.html
The following gives the bogus error:
write(lu,'(a)') 'UNIT '//UpperCase(UNAME(1))
1
Error: Variable 'str' is used at (1) before the ENTRY statement in which it is
a parameter
subroutin
I installed http://quatramaran.ens.fr/~coudert/gfortran/gfortran-windows.exe
I found that the version of gdb included with gfortran-windows.exe does not
work, but the version of gdb included with Cygwin does. When I type:
c:\progra~1\gfortran\bin\gfortran -g test.f90
c:\progra~1\gfortran\bin\gdb
--- Comment #6 from manu at gcc dot gnu dot org 2007-10-19 14:46 ---
Just for reference. Neither fprintf() nor sprintf() seem to follow the
behaviour of printf() in glibc 2.5.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15685
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-10-19 14:10
---
Fixed.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-10-19 14:09
---
Subject: Bug 33544
Author: jvdelisle
Date: Fri Oct 19 14:09:27 2007
New Revision: 129489
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129489
Log:
2007-10-19 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-10-19 14:06
---
Subject: Bug 33544
Author: jvdelisle
Date: Fri Oct 19 14:06:05 2007
New Revision: 129488
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129488
Log:
2007-10-19 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-19 12:52 ---
The gcc.c-torture/execute/20001024-1.c testcase introduced with r37052 no
longer fails without the hack in layout_type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33816
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-10-19 12:40
---
Complete mess. Can of worms. Unassigning.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
The testcase from PR32921 shows that we end up with an alias set of zero for
real8[0:] because in both functions this type is used in casts. When the
first function is gimplified the gimplifier asks if the cast is a useless
type conversion which in turn calls get_alias_set which sets the alias set
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-10-19 12:27
---
Subject: Bug 32921
Author: rguenth
Date: Fri Oct 19 12:27:25 2007
New Revision: 129487
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129487
Log:
2007-10-19 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #6 from pcarlini at suse dot de 2007-10-19 11:26 ---
Actually, would be:
Index: random
===
--- random (revision 129456)
+++ random (working copy)
@@ -1607,7 +1607,8 @@
{
typedef type
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-10-19 11:26
---
Subject: Bug 32921
Author: rguenth
Date: Fri Oct 19 11:25:55 2007
New Revision: 129484
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129484
Log:
2007-10-19 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #5 from pcarlini at suse dot de 2007-10-19 10:49 ---
To wit, this kind of change, you can certainly apply it to the 4.2.1 headers
as-is:
Index: random
===
--- random (revision 129456)
+++ random (worki
--- Comment #4 from pcarlini at suse dot de 2007-10-19 10:46 ---
I'm going to commit to mainline a stop-gap solution. If you could confirm, as I
believe, that it's at least an improvement, we can have it in 4_2-branch too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33815
--- Comment #3 from jkherciueh at gmx dot net 2007-10-19 10:13 ---
> Actually, the problem happens only for some specific values of the range, like
> eng.max() / 5.5, dividing by 2 or 10 is ok. Indeed, seems a binary arithmetic
> problem.
I conjecture that the problem happens if and onl
--- Comment #5 from brakiozor at caramail dot com 2007-10-19 10:06 ---
yes, one of the way is to pass by an intermediate template type...
(I found it on the web)
but the compiler error could(and should) be fixed
#define TPL_TYPEOF_MUL(A,B) typename typeof_mul::type
#define TYPEOF_MUL(A,
1 - 100 of 104 matches
Mail list logo
