--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-05-28 09:18
---
Confirmed, Gigi is not prepared for this kind of circularity.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
file-a.c:
-
void __attribute__((weak)) func(void)
{
/* no code */
}
main()
{
func();
}
file-b.c:
-
void func(void)
{
printf("func\n");
}
# gcc -c file-a.c file-b.c -O2
# gcc -o program file-a.o file-b.o
The program will not print "func", because the call to func()
There is a problem in data dependence analysis that breaks bootstrap with
-ftree-vectorize (or any other flag that causes find_data_references_in_loop to
be called):
stage1/xgcc -Bstage1/ -B/usr/local/i686-pc-linux-gnu/bin/ -c -g -O2 -msse2
-ftree-vectorize -DIN_GCC -W -Wall -Wwrite-strings -W
--- Comment #1 from pault at gcc dot gnu dot org 2006-05-28 09:45 ---
Created an attachment (id=11523)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11523&action=view)
Patch to fix bug
I will submit this tonight; regtests on FC5/Athlon1700
Paul
--
http://gcc.gnu.org/bugzilla
The following malformed program is not diagnosed:
#include "stdio.h" "bar"
-Chris
--
Summary: Garbage at end of #include line ignored
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
--- Comment #4 from steven at gcc dot gnu dot org 2006-05-28 09:50 ---
It is sad that this is not release critical, and even worse that the
contributor of vrp apparently can't miss half an hour to document his work as
he is required to do.
--
steven at gcc dot gnu dot org changed:
--- Comment #4 from steven at gcc dot gnu dot org 2006-05-28 09:53 ---
This looks like one that the mem-ssa folks may want to give a look.
Will it be easier in mem-ssa to attach alias info to INDIRECT_REF nodes?
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from familie dot glaser at web dot de 2006-05-28 10:12
---
Right, but this only shows that the "value tracking" based optimization works
very well. The volatile crap is used to point out an example for situations in
which the optimizer must loose the values track. This re
$ cat string_null_compare_1.f
program main
character*3 str1, str2
call setval(str1, str2)
if (str1 == str2) print *,'Should be unqual'
end
subroutine setval(str1, str2)
character*3 str1, str2
str1 = 'a' // CHAR(0) // 'a'
str2 = 'a' // CHAR(0) /
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reco
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-05-28 11:50 ---
Then provide a real testcase please. With this report nothing is going to be
done because in the testcase, the volatiles are just "crap".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27771
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-28 12:03 ---
ipa-pure-const thinks that func is const, which is wrong. Then DCE comes along
and deletes the function call.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-28 12:07
---
(In reply to comment #3)
> FX, Are you comming to the GCC summit?
Well, my employer has nothing to do with gfortra, so I won't be coming. But if
you ever come to Paris, I'll offer you a beer!
--
http://gcc.g
--- Comment #3 from pault at gcc dot gnu dot org 2006-05-28 12:11 ---
Arjen,
> I tried this with gfortran 4.20 too (the report file was indeed
> created with 4.1, but the result with the newer version was quite the
> same). It happens when I build version 5.6.1 of PLplot (http://plplot.
--- Comment #11 from tkoenig at gcc dot gnu dot org 2006-05-28 12:33
---
(In reply to comment #10)
>
> Not committing right now.
Downloading a fresh version via svn cured that problem.
I'd have commited the patch by now, but for some strange reason,
I get "Authentication failed" error
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-28 13:23
---
I tried with the following reduced testcase:
implicit none
integer :: i
logical :: l
type dt
integer, pointer :: a => null()
end type dt
type(dt), pointer :: obj(:) => null()
allocate(obj(2))
This reduced testcase is originally from the testsuite
gfortran.dg/cray_pointers_2.f90. It generates an incorrect out-of-bounds error
message when run with bounds-checking enabled.
$ cat cray_pointers_2.f90
integer targ(2)
integer pte
pointer(ptr,pte(*))
ptr = loc(targ)
targ(2) = -1
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-28 14:00 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org
--- Comment #2 from pault at gcc dot gnu dot org 2006-05-28 14:09 ---
Created an attachment (id=11524)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11524&action=view)
Patch for the bug exposed by the fix to this and PR25098
The patch for pr25098 fixes this bug but exposes another
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-05-28 14:10 ---
(In reply to comment #3)
> Dunno if tree loop reversal is already there, but Zdenek probably likes to
> know
> what bugs he is fixing...
Loop reversal doesn't occur yet.
gcc version 4.2.0 20060521 (experimental) g
--- Comment #12 from berndtrog at yahoo dot com 2006-05-28 14:10 ---
> --- Comment #11 from laurent at guerby dot net 2006-05-27 18:41 ---
> Bernd, could you contribute (attach here) your Makefile and ada RTS changes so
> that Ada build with AVR target succeeds?
Since I don't l
--- Comment #5 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-05-28 14:25 ---
Subject: Re: Reverse loop order for increased efficiency
> --- Comment #4 from tkoenig at gcc dot gnu dot org 2006-05-28 14:10
> ---
> (In reply to comment #3)
> > Dunno if tree loop
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-05-28 14:53 ---
It's even worse:
$ cat cmp.f
program main
external isgreater
logical isgreater
print *,"a" > "ä"
print *,isgreater("a", "ä")
end
logical function isgreater(s1, s2)
ch
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-28 15:20 ---
volatile makes all the optimizations turn off for that variable which means
nothing is going to happen.
This is not a bug, if you can find a testcase without volatile, please file a
new bug.
--
pinskia at gcc do
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-28 15:23 ---
Actually no, you have to use -fPIC to get this not to be optimized, otherwise
func will be bound locally which is not what you want.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from patchapp at dberlin dot org 2006-05-28 15:37 ---
Subject: Bug number PR25098
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/2006-05/msg01425.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-28 15:47 ---
*** This bug has been marked as a duplicate of 27331 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-28 15:47 ---
*** Bug 27782 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-28 15:49
---
What about simply doing:
Index: intrinsics/string_intrinsics.c
===
--- intrinsics/string_intrinsics.c (revision 113849)
+++ intrinsics/string_i
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-28 15:59
---
Created an attachment (id=11525)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11525&action=view)
Proposed patch
I'm tempted to propose the attached patch. It makes the front-end ultimately
use unsigned cha
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-05-28 16:05 ---
(In reply to comment #1)
> What about simply doing:
>
> Index: intrinsics/string_intrinsics.c
> ===
> --- intrinsics/string_intrinsics.c (revision
--- Comment #12 from kazu at gcc dot gnu dot org 2006-05-28 16:06 ---
Subject: Bug 26622
Author: kazu
Date: Sun May 28 16:06:36 2006
New Revision: 114167
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114167
Log:
gcc/
PR tree-optimization/26622.
* fold-const.c (f
--- Comment #13 from kazu at gcc dot gnu dot org 2006-05-28 16:07 ---
Now fixed on 4.1.2 and on.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
Su
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-05-28 16:10 ---
(In reply to comment #3)
> Created an attachment (id=11525)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11525&action=view) [edit]
> Proposed patch
>
> I'm tempted to propose the attached patch. It makes the
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-28 16:28
---
(In reply to comment #2)
> In the meantime, this patch is approved :-)
No, your patch is approved! Please go ahead and commit :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27784
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-28 16:32
---
(In reply to comment #4)
> unsigned char *string;
Humpf, I don't know. I don't think it's the best course of action... too
invasive.
> As far as the collating sequence goes... should we eventually
> suppor
--- Comment #6 from kargl at gcc dot gnu dot org 2006-05-28 16:52 ---
Guys,
Have you read 4.3.2.1.1? This defines the requirements on the
collating of the default character type. It also defines the
requirements on LGT, LGE, LLE, and LLT, which is why we use the
ascii_table in simplif
// The code has been tested with GCC 3.4.2, 4.1.1 and 4.2.0 (alpha) and fails.
// It compiles successfully with Comeau (>= 4.2) and VisualC++ (>=7.1).
template
struct x
{
template
struct y
{
typedef Y type;
};
};
template
struct a : x
{
// supposed to fail (unqualified lookup does n
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-28 18:42 ---
There is a defect report about this if a is really a dependent name or not (or
maybe it is the one about inherite and template and name lookup I forget).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27787
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-28 18:43 ---
Replacing a with x, makes this work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27787
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-28 18:51 ---
http://std.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#213
And
http://std.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#108
Both seems a way to better understand this but I am confused with what the
standard says
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-28 18:53 ---
[kudzu:trunk/objdir/gcc] pinskia% ./xgcc -B. t.c
t.c:1:20: warning: extra tokens at end of #include directive
h.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27783
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-28 18:55 ---
This is a bug in Apple's GCC as I cannot reproduce it in the FSF released
3.4.0, 4.0.0, 4.1.0 or 4.2.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-28 18:56 ---
I should note I could reproduce it with Apple's GCC though.
It has warned since 3.0.4, while 2.95.3 did:
earth:~>~/ia32_linux_gcc2_95//bin/gcc t.c
t.c:1: stdio.hbar: No such file or directory
--
http://gcc.gnu.o
--- Comment #2 from bangerth at dealii dot org 2006-05-28 18:58 ---
(In reply to comment #0)
> I'm not quite sure whether writing "class" before "A::B::C" is valid
> or has to be replaced by "typename".
This is the subject of DR 180.
W.
--
bangerth at dealii dot org changed:
--- Comment #13 from ray at ultramarine dot com 2006-05-28 19:06 ---
Subject: Re: [4.1/4.2 Regression] Problems with direct
access io
On Sat, 28 May 2006, jvdelisle at gcc dot gnu dot org wrote:
>
>
> --- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-05-28 00:40
> --
--- Comment #8 from pault at gcc dot gnu dot org 2006-05-28 19:47 ---
Subject: Bug 25746
Author: pault
Date: Sun May 28 19:46:22 2006
New Revision: 114173
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114173
Log:
2006-05-28 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #21 from pault at gcc dot gnu dot org 2006-05-28 19:47 ---
Subject: Bug 27155
Author: pault
Date: Sun May 28 19:46:22 2006
New Revision: 114173
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114173
Log:
2006-05-28 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #9 from pault at gcc dot gnu dot org 2006-05-28 19:47 ---
Subject: Bug 27411
Author: pault
Date: Sun May 28 19:46:22 2006
New Revision: 114173
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114173
Log:
2006-05-28 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #9 from pault at gcc dot gnu dot org 2006-05-28 19:47 ---
Subject: Bug 19015
Author: pault
Date: Sun May 28 19:46:22 2006
New Revision: 114173
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114173
Log:
2006-05-28 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #5 from pault at gcc dot gnu dot org 2006-05-28 19:47 ---
Subject: Bug 25082
Author: pault
Date: Sun May 28 19:46:22 2006
New Revision: 114173
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114173
Log:
2006-05-28 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #12 from pault at gcc dot gnu dot org 2006-05-28 19:47 ---
Subject: Bug 27449
Author: pault
Date: Sun May 28 19:46:22 2006
New Revision: 114173
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114173
Log:
2006-05-28 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #8 from pault at gcc dot gnu dot org 2006-05-28 19:47 ---
Subject: Bug 27613
Author: pault
Date: Sun May 28 19:46:22 2006
New Revision: 114173
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114173
Log:
2006-05-28 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #5 from pault at gcc dot gnu dot org 2006-05-28 19:47 ---
Subject: Bug 27584
Author: pault
Date: Sun May 28 19:46:22 2006
New Revision: 114173
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114173
Log:
2006-05-28 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #8 from pault at gcc dot gnu dot org 2006-05-28 19:47 ---
Subject: Bug 27709
Author: pault
Date: Sun May 28 19:46:22 2006
New Revision: 114173
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114173
Log:
2006-05-28 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #6 from pault at gcc dot gnu dot org 2006-05-28 19:51 ---
Subject: Bug 27584
Author: pault
Date: Sun May 28 19:50:51 2006
New Revision: 114174
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114174
Log:
2006-05-28 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #6 from pault at gcc dot gnu dot org 2006-05-28 19:51 ---
Subject: Bug 25082
Author: pault
Date: Sun May 28 19:50:51 2006
New Revision: 114174
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114174
Log:
2006-05-28 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #9 from pault at gcc dot gnu dot org 2006-05-28 19:51 ---
Subject: Bug 25746
Author: pault
Date: Sun May 28 19:50:51 2006
New Revision: 114174
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114174
Log:
2006-05-28 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #10 from pault at gcc dot gnu dot org 2006-05-28 19:51 ---
Subject: Bug 27411
Author: pault
Date: Sun May 28 19:50:51 2006
New Revision: 114174
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114174
Log:
2006-05-28 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #9 from pault at gcc dot gnu dot org 2006-05-28 19:51 ---
Subject: Bug 27709
Author: pault
Date: Sun May 28 19:50:51 2006
New Revision: 114174
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114174
Log:
2006-05-28 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #22 from pault at gcc dot gnu dot org 2006-05-28 19:51 ---
Subject: Bug 27155
Author: pault
Date: Sun May 28 19:50:51 2006
New Revision: 114174
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114174
Log:
2006-05-28 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #9 from pault at gcc dot gnu dot org 2006-05-28 19:51 ---
Subject: Bug 27613
Author: pault
Date: Sun May 28 19:50:51 2006
New Revision: 114174
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114174
Log:
2006-05-28 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #10 from pault at gcc dot gnu dot org 2006-05-28 19:51 ---
Subject: Bug 19015
Author: pault
Date: Sun May 28 19:50:51 2006
New Revision: 114174
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114174
Log:
2006-05-28 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #11 from pault at gcc dot gnu dot org 2006-05-28 19:52 ---
Fixed in trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pault at gcc dot gnu dot org 2006-05-28 19:53 ---
Fixed in trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pault at gcc dot gnu dot org 2006-05-28 19:54 ---
Fixed in trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pault at gcc dot gnu dot org 2006-05-28 19:54 ---
Fixed in trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pault at gcc dot gnu dot org 2006-05-28 19:55 ---
Fixed in trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pault at gcc dot gnu dot org 2006-05-28 19:56 ---
Fixed in trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-05-28 19:56
---
(In reply to comment #6)
> Have you read 4.3.2.1.1? This defines the requirements on the
> collating of the default character type. It also defines the
> requirements on LGT, LGE, LLE, and LLT, which is why we u
--- Comment #10 from pault at gcc dot gnu dot org 2006-05-28 19:57 ---
Fixed in trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from pault at gcc dot gnu dot org 2006-05-28 19:58 ---
Fixed in trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-28 20:03 ---
(In reply to comment #7)
> (In reply to comment #6)
> > Have you read 4.3.2.1.1? This defines the requirements on the
> > collating of the default character type. It also defines the
> > requirements on LGT, LGE, L
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-05-28 20:05 ---
(In reply to comment #7)
> Yes, but C strings are char by default and not unsigned char, so I guess we'd
> best avoid changing that. But, a less invasive fix could be:
And char can either default to unsigned or sign
--- Comment #12 from tkoenig at gcc dot gnu dot org 2006-05-28 20:36
---
Subject: Bug 27470
Author: tkoenig
Date: Sun May 28 20:35:53 2006
New Revision: 114176
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114176
Log:
2005-05-28 Thomas Koenig <[EMAIL PROTECTED]>
PR
--- Comment #13 from tkoenig at gcc dot gnu dot org 2006-05-28 20:37
---
Fixed on trunk and 4.1.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-28 20:47 ---
Something is removing the store to _M_start.
this_252 = (struct _Vector_base > *) &b;
this_253 = this_252;
# VUSE ;
D.13530_256 = this_252->_M_impl._M_start;
I think the cast there is causing the problem
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-28 20:50 ---
This is related to PR 19817, the C++ front-end is producing that construct
which causes us not to constant prop zero.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27768
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-28 20:52 ---
But even without fixing PR 19817, it seems like the cast should be valid, or
maybe not someone who knows if the cast is valid in C++ where the struct is not
an inheirtance.
--
pinskia at gcc dot gnu dot org chang
--- Comment #4 from tschwinger at neoscientists dot org 2006-05-28 21:47
---
It seems my report is missing some detail.
Here's my apology and an attempt to outline my standard interpretation that
makes me think it is a bug.
(In reply to comment #0)
>
> template
> struct x
> {
> te
The well-formed program below fails to compile with gcc 4.1.0:
$ cat t.cpp && gcc -c t.cpp
template void foo (T*) { }
typedef void F ();
F* f = (F*)&foo;
t.cpp:5: error: address of overloaded function with no contextual type
information
--
Summary: error casting address of a funct
This revision to gcc/cp
2006-05-24 Mark Mitchell <[EMAIL PROTECTED]>
PR c++/20103
* decl.c (cp_make_fname_decl): Don't set DECL_INITIAL to
error_mark_node to indicate an initialization is OK.
(start_decl): Likewise. Adjust call to start_decl_1.
(start_de
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-29 00:12 ---
It is only valid after DR 115. This is a dup of bug 11407.
*** This bug has been marked as a duplicate of 11407 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |A
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-05-29 00:12 ---
*** Bug 27788 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from amodra at bigpond dot net dot au 2006-05-29 02:48
---
Note that fctidz is used because we are converting to unsigned. gcc uses
fctiwz if converting to int. Of course, it isn't correct to simply replace
fctidz with fctiwz.. To get this right, gcc would need to gene
--- Comment #6 from amodra at bigpond dot net dot au 2006-05-29 02:52
---
Oh, I suppose rounding might change the result if we always subtract off
2**(n-1).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27682
--- Comment #1 from amodra at bigpond dot net dot au 2006-05-29 03:07
---
Confirmed. The reference is the relocation for DW_AT_const_value.
$ readelf -wi test.o
[snip]
<1><7a>: Abbrev Number: 8 (DW_TAG_variable)
DW_AT_name: (indirect string, offset: 0x0): gconf_g_utf8_ski
[EMAIL PROTECTED] ~ $ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1/configure --prefix=/home/halcyon/gcc-test/bin-4.1/
--enable-languages=c,c++
Thread model: posix
gcc version 4.1.2 20060529 (prerelease)
gcc -c -ftree-vectorize -O1 -msse2 test.i
test.i: In func
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-29 04:28 ---
Confirmed, the bug is in ix86_expand_int_vcond.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-29 04:31 ---
This also can be reproduced on x86_64:
void binarize (int npixels, unsigned char *b)
{
int i;
for (i = 0; i < npixels; i++)
b[i] = (b[i] > 225 ? 0xff : 0);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2006-05-29 05:19
---
Subject: Bug 24459
Author: jvdelisle
Date: Mon May 29 05:18:58 2006
New Revision: 114182
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114182
Log:
2006-05-28 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2006-05-29 05:22
---
Subject: Bug 24459
Author: jvdelisle
Date: Mon May 29 05:22:05 2006
New Revision: 114184
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114184
Log:
2006-05-28 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2006-05-29 05:23
---
Fixed now on 4.1
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-05-29 06:44
---
Subject: Bug 26818
Author: reichelt
Date: Mon May 29 06:44:46 2006
New Revision: 114187
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114187
Log:
PR c/26818
* c-decl.c (finish_struct): Ski
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-05-29 06:50
---
Subject: Bug 27451
Author: reichelt
Date: Mon May 29 06:50:07 2006
New Revision: 114189
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114189
Log:
PR c++/27451
* stmt.c (expand_asm_operands
--- Comment #4 from arjen dot markus at wldelft dot nl 2006-05-29 06:54
---
Subject: Re: Linking example programs for PLplot causes
error messages about multiple definition of __gfortran_transfer_character
pault at gcc dot gnu dot org wrote:
>--- Comment #3 from pault at gcc dot
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-05-29 06:56
---
Subject: Bug 27716
Author: reichelt
Date: Mon May 29 06:56:07 2006
New Revision: 114190
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114190
Log:
PR c++/27716
* typeck.c (build_modify_expr
99 matches
Mail list logo
