--- Comment #3 from sherpya at netfarm dot it 2005-12-11 08:09 ---
looking at gcc/Makefile
ORIGINAL_LD_FOR_TARGET =
./j:/mingw/bin/../lib/gcc/mingw32/4.0.2/../../../../mingw32/bin/ld.exe
ORIGINAL_NM_FOR_TARGET = /mingw/bin/nm
so LD path takes a : that interfers with make,
on gcc 402 it
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2005-12-11 08:09
---
Patch submitted for approval.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25264
$ cat t.f
program main
character(len=10) line
write (*,'(1X,A,T1,A)') 'A','B'
write (line,'(1X,A,T1,A)') 'A','B'
print '(A)',line
end
$ gfortran t.f
$ ./a.out
B
BA
$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../gcc/trunk/conf
--- Comment #8 from martin at mpa-garching dot mpg dot de 2005-12-11 09:40
---
I re-tested today with versions 3.3.2, 4.0-branch, 4.1-branch, trunk and
gomp-branch, and could not reproduce the regression any more.
So I think this report can be closed. Thanks to the unknown patcher! ;)
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-12-11 10:20
---
I *hate* T format descriptors. And I thought we had this topic working and
covered by the testsuite.
This is not a regression, though, since 4.0.3 segfaults on this same example.
--
fxcoudert at gcc dot gnu d
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2005-12-11 10:52
---
So, following Steven's question on c.l.f, this code is illegal.
Most compilers report an EOF error (including Intel and g77), and branch if an
END tag is present. I think the error issued by gfortran currently is
--- Comment #2 from tkoenig at gcc dot gnu dot org 2005-12-11 10:57 ---
(In reply to comment #1)
> I *hate* T format descriptors. And I thought we had this topic working and
> covered by the testsuite.
The testsuite often uses internal writes. I just converted tl_editing.f90
to use ext
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2005-12-11 12:51
---
(In reply to comment #2)
> It does work with g77. Why did you remove PR 19292?
Sorry, must have been a wrong keypress, didn't mean to do it.
Another thing. I updated my tree (Thomas' convert patch got in) and t
382: error: can't convert between vector values of different size
It works okay with older versions of gcc, and fails with 4.2.0 20051211
both with the
include file that ships with it and with it's older versions.
Environment:
System: Linux amazonia 2.6.10-5-386 #1 Mon Oct
coverage_checksum_string function in gcc/coverage.c fails (SIGSEGV) with this
input:
=
_GLOBAL__D__ZN5boost9unit_test88_GLOBAL__N_C__work_FlexIDE_libs_boost_libs_test_src_unit_test_main.cpp__17results_collectorE
=
This function is called if compilati
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-12-11 13:59
---
(In reply to comment #3)
> Does someone else see this?
Answering to myself: it disappeared with a clean build.
As for the cause of the problem, it's truncation after the last character
write. Another slightly di
--- Comment #1 from cyberax at elewise dot com 2005-12-11 14:10 ---
Created an attachment (id=10450)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10450&action=view)
Quick fix
Quick-and-dirty fix for this bug (works for me).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2535
If you use an xfail command within a dg-do, it has no effect. E.g this generic
testcase will FAIL rather than XFAIL:
/* { dg-do preprocess { xfail *-*-* } } */
#error intentional failure!
int main(void)
{
return 0;
}
Right now, none of the ~100 testcases in the testsuite using this idiom are
--- Comment #1 from ghazi at gcc dot gnu dot org 2005-12-11 15:14 ---
We probably should have some sort of dg conformance test directory with simple
tests ensuring all the directives work as advertised.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25352
--- Comment #1 from danglin at gcc dot gnu dot org 2005-12-11 15:47 ---
Proposed fix is here:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00325.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25168
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-11 15:52 ---
Do you have a normal testcase that is C++ which produces this symbol?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from danglin at gcc dot gnu dot org 2005-12-11 16:00 ---
Proposed fix is here:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00820.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25171
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-11 16:12 ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00822.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from danglin at gcc dot gnu dot org 2005-12-11 16:12 ---
Subject: Bug 24478
Author: danglin
Date: Sun Dec 11 16:12:48 2005
New Revision: 108382
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108382
Log:
PR testsuite/25167
PR testsuite/24478
--- Comment #3 from danglin at gcc dot gnu dot org 2005-12-11 16:12 ---
Subject: Bug 25167
Author: danglin
Date: Sun Dec 11 16:12:48 2005
New Revision: 108382
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108382
Log:
PR testsuite/25167
PR testsuite/24478
--- Comment #3 from cyberax at elewise dot com 2005-12-11 16:23 ---
Yes, preprocessed file attached. But this bug is somewhat hard to reproduce,
I've spent about 3 hours trying to create a minimal test-case without much
success - sometimes compilation is finished successfully, but the r
--- Comment #14 from cyberax at elewise dot com 2005-12-11 16:25 ---
Created an attachment (id=10451)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10451&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16589
--- Comment #4 from cyberax at elewise dot com 2005-12-11 16:29 ---
Created an attachment (id=10452)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10452&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25351
--- Comment #5 from kargl at gcc dot gnu dot org 2005-12-11 16:47 ---
http://gcc.gnu.org/ml/fortran/2005-12/msg00215.html
This patch changes the handling of labels to catch
problems with too many digits from laeding zeros.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25106
--- Comment #2 from kargl at gcc dot gnu dot org 2005-12-11 16:47 ---
Patch http://gcc.gnu.org/ml/fortran/2005-12/msg00215.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25055
--- Comment #2 from kargl at gcc dot gnu dot org 2005-12-11 17:06 ---
I have a tentative patch for this bug.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
There is a need for an automated testsuite so that when convert libobjc not to
use GCC's target headers, it can actually be tested.
--
Summary: There should be an automated testsuite for
objc_sizeof_type and objc_alignof_type
Product: gcc
Vers
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-11 17:48 ---
Mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2005-12-11 17:54
---
This is simialr to pr25264. I had to fix a regression in tl-editing, so maybe
i need to extend that to the regular files. I was beginning to wonder why
internal units seemed so different fromn files. Perhaps th
The test case:
#include
using namespace std;
int main()
{
unsigned int test = 1067320345;
cout << reinterpret_cast(test) << endl;
cout << "reinterpret_cast(test): " <<
reinterpret_cast(test) << endl;
}
When compiled using -g or -O1, the correct output is produced:
1.2345
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-11 17:58 ---
You are violating C/C++ aliasing rules.
*** This bug has been marked as a duplicate of 21920 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #80 from pinskia at gcc dot gnu dot org 2005-12-11 17:58
---
*** Bug 25355 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
The -MT option with -MMD is supposed to substitute for the target
in the generated makefile. In most cases it seems to do so. However (using the
attached file, which is a rename .ii file), the command:
g++ -c -o accum.o -MMD accum.cc
produces the makefile:
accum.o: accum.cc
as expected
--- Comment #1 from igodard at pacbell dot net 2005-12-11 18:43 ---
Created an attachment (id=10453)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10453&action=view)
source code (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25356
--- Comment #3 from kargl at gcc dot gnu dot org 2005-12-11 18:45 ---
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00826.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25078
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-11 18:46 ---
*** This bug has been marked as a duplicate of 12448 ***
*** This bug has been marked as a duplicate of 12448 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-11 18:46 ---
*** Bug 25356 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from igodard at pacbell dot net 2005-12-11 18:57 ---
Reported *and patched* two years ago and still not fixed? What gives?
Ivan
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25356
La cuenta a la que has tratado de enviar el mail no existe, favor de
confirmarla.
--- Comment #4 from sherpya at netfarm dot it 2005-12-11 20:41 ---
My latest build unaffected from this bug is 4.1.0 cvs 20051013 (now I've
switched to svn), anyway fixing the ld path compiles fine.
--
sherpya at netfarm dot it changed:
What|Removed
--- Comment #9 from aoliva at gcc dot gnu dot org 2005-12-11 20:54 ---
IMHO it's better to add a new option with the desired meaning than modifying
the behavior of the current option. -print-multi-search-dirs maybe?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20425
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-11 21:53 ---
Fixed in 4.0.x.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-11 23:19 ---
This is fixed in 4.1.0 as what is happening before was the friend was injecting
when it should not have been. This was fixed by the patch which fixed PR 7874.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-11 23:24 ---
I think I Know why this shows up this way, we lower typeid(T) very early on.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from amodra at gcc dot gnu dot org 2005-12-12 01:28 ---
Subject: Bug 25299
Author: amodra
Date: Mon Dec 12 01:28:50 2005
New Revision: 108393
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108393
Log:
PR target/25299
* config/rs6000/rs6000.c (rs600
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-12-12 01:40
---
Subject: Bug 25337
Author: mmitchel
Date: Mon Dec 12 01:40:25 2005
New Revision: 108394
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108394
Log:
PR c++/25337
* pt.c (tsubst_copy_and_buil
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-12-12 01:41
---
Subject: Bug 25337
Author: mmitchel
Date: Mon Dec 12 01:41:16 2005
New Revision: 108395
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108395
Log:
PR c++/25337
* pt.c (tsubst_copy_and_buil
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-12-12 01:42
---
Subject: Bug 25337
Author: mmitchel
Date: Mon Dec 12 01:42:33 2005
New Revision: 108396
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108396
Log:
PR c++/25337
* pt.c (tsubst_copy_and_buil
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-12-12 01:43
---
Fixed in 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Summa
--- Comment #21 from pinskia at gcc dot gnu dot org 2005-12-12 02:38
---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00832.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-12 02:45 ---
: Search converges between 2003-10-17-trunk (#379) and 2003-10-18-trunk (#380).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25342
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-12-12 02:46 ---
Fixed so closing as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-12 02:50 ---
: Search converges between 2002-02-17-trunk (#59) and 2002-02-24-trunk (#60).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25309
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-12 02:55 ---
Hmm, I almost want to say this was caused by:
2002-02-20 Roger Sayle <[EMAIL PROTECTED]>
Jakub Jelinek <[EMAIL PROTECTED]>
PR c/4389
* tree.c (host_integerp): Ensure that the constant
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-12 03:01 ---
: Search converges between 2003-04-16-trunk (#231) and 2003-04-17-trunk (#232).
>From that I almost think it was orginally caused by (but I should note that the
4.0 regression would have been caused by the change ov
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-12 03:09 ---
: Search converges between 2004-09-20-161001-trunk (#551) and
2004-09-21-094824-trunk (#552).
Looks like this was caused by:
2004-09-20 Matt Austern <[EMAIL PROTECTED]>
Zack Weinberg <[EMAIL PROTECTED
The following code fails on 3.3.6 and 3.4.5. It does work on 4.0.2 and 4.1.0,
so I'm not sure if a fix would be backported to the 3.4 branch.
#include
using namespace std;
class A
{
public:
A ();
virtual int a() = 0;
};
int main(void)
{
A *B;
typeid(typeid(*B)
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Known to work|4.0.2 4.1.0 |4.0
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-12 04:30 ---
Confirmed, only a 3.4 regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
I must confess I don't much about cray pointers, but the model I work on
contains a bunch of them. Therefore I can't provide a reduced testcase of this,
but i'm attaching a code that proceduces the error.
The code is valid according to lahey source checker (if fixed form), and
compiles (and execute
--- Comment #1 from deji_aking at yahoo dot ca 2005-12-12 05:08 ---
Created an attachment (id=10454)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10454&action=view)
Code that produces above error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25358
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-12 05:47 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-12 05:47 ---
Subject: Bug 25354
Author: pinskia
Date: Mon Dec 12 05:47:52 2005
New Revision: 108398
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108398
Log:
2005-12-12 Andrew Pinski <[EMAIL PROTECTED]>
PR li
The objc.dg-struct-layout-encoding-1 failures happen on ppc-darwin:
FAIL: objc.dg-struct-layout-encoding-1/t003_main.m execution test
FAIL: objc.dg-struct-layout-encoding-1/t004_main.m execution test
FAIL: objc.dg-struct-layout-encoding-1/t006_main.m execution test
FAIL: objc.dg-struct-layout-encod
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-12 05:51 ---
Mine, I am working on this via PR 24775.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The following testsuite fails because of this
FAIL: objc.dg-struct-layout-encoding-1/t024_main.m execution test
unknown type ]}
struct { _Complex float a;} size is 8, but is calulated as 0
struct { _Complex float a;} align is 4, but is calulated as 1
struct { _Complex unsigned int a;} size is 8, b
The following testsuite failures is because of this:
FAIL: objc.dg-struct-layout-encoding-1/t025_main.m execution test
unknown type ]}
struct { v4hi a;} size is 8, but is calulated as 0
struct { v4hi a;} align is 8, but is calulated as 1
FAIL: objc.dg-struct-layout-encoding-1/t025_main.m execution
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-12 05:55 ---
I should note that this causes all of objc.dg-struct-layout-encoding-1 tests to
fail on x86_64 and i?86.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25348
--- Comment #6 from Uwe dot Seimet at seimet dot de 2005-12-12 06:21
---
Subject: Re: [3.4/4.0/4.1/4.2 Regression] Unreachable code at beginning of
switch statement is not reported anymore
Hello,
Another comment from my side: When using -Wunreachable-code as a means
to detect unreach
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
70 matches
Mail list logo
