when compiling the attached gcc4bug.c with
$ gcc -Wall -O2 -fno-strict-aliasing gcc4bug.c -o gcc4bug;./gcc4bug ;echo $?
39
the assertion in line 39 gets triggered on ppc64, even though
-fno-strict-aliasing is used; looking at the assembler output, the 2 single-byte
stores (together with the asse
--- Additional Comments From hvr at gnu dot org 2005-05-28 07:50 ---
Created an attachment (id=8983)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8983&action=view)
C file triggering the issue
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21795
When merging to release branches the work on we have to resolve
this issue: the new unified std::search doesn't exploit std::find, and a small
performance regression is possible, in theory: at least benchmark. FWIW, in
mainline, we have an inconsistency instead: only the version not taking a
predi
--- Additional Comments From pcarlini at suse dot de 2005-05-28 07:59
---
Please, consider encapsulating the errata in the implementation of the builtins.
During the next years these facilities will be used more and more, in the C++
runtime and elsewhere, of course: if people have to pro
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-28
08:08 ---
Note there is no C alias rules violating in the code as you can access anything
via chars.
--
What|Removed |Added
---
On alpha-linux, I see the following testsuite failures:
gfortran.dg/f2c_2.f90
gfortran.dg/g77/cabs.f
gfortran.dg/g77/f90-intrinsic-mathematical.f
gfortran.fortran-torture/execute/csqrt_1.f90
gfortran.fortran-torture/execute/intrinsic_abs.f90
gfortran.fortran-torture/execute/math.f90
gfortran.fort
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-05-28 10:45
---
c90-const-expr-2.c and c99-const-expr-2.c already contain assertions that
(void *)(void *)0 is not a null pointer constant; this just part of the known
constant expressions issues.
*** This bug has been mark
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-05-28 10:45
---
*** Bug 21794 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
What|Removed |Added
OtherBugsDependingO||16620, 16989
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=217
Please could we have a generational garbage collector for libgcj? Garbage
collection delays can be quite unacceptable for desktop apps on my Athlon XP
1800+.
--
Summary: Generational garbage collector?
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
--- Additional Comments From henri dot gomez at gmail dot com 2005-05-28
11:40 ---
Subject: Re: libstdc++ build failed on AIX 5.2
Redone a test and now I've got :
checking for isnanf declaration... no
checking for _isnanf declaration... yes
checking for _isnanf... yes
checking for isi
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-28
14:01 ---
Note, you are violating not aliasing rules but rule of going over the bounds of
the array which is
undefined by the C standard.
--
What|Removed |Added
-
--- Additional Comments From kargl at gcc dot gnu dot org 2005-05-28 14:39
---
FX,
On i386-*-freebsd, -fdump-tree-original shows
MAIN__ ()
{
complex4 z;
complex4 c;
z = __complex__ (4.0e+0, 0.0);
c = csqrtf (z);
kargl[214] find . -type f | xargs grep csqrtf
./gcc/
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-28
14:40 ---
Please submit each bug separately with the preprocessed source as requested by
the web page.
--
What|Removed |Added
-
--- Additional Comments From sgk at troutmask dot apl dot washington dot
edu 2005-05-28 15:48 ---
Subject: Re: complex(4) sqrt failures on alpha-linux
On Sat, May 28, 2005 at 02:39:19PM -, kargl at gcc dot gnu dot org wrote:
>
> If we look through libgfortran/generated/exp_c4.c, w
This 4.1 regression is going to break one of the proposed benchmarks in
spec2005. I believe that we have established that this code
-
template void f (T &, void (T::*)() );
template void f (const T &, void (T::*)() const);
struct X {
void g() con
--
What|Removed |Added
Severity|normal |critical
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21
`gcc-4.0 -Wall -O2' on the attached piece of code produces the following
warning:
s.c: In function 'main':
s.c:15: warning: control may reach end of non-void function 'xtoi' being inlined
which doesn't make much sense as assert_failed() is known not to return. If I
remove the `if (1)', the warni
--- Additional Comments From mj at ucw dot cz 2005-05-28 17:43 ---
Created an attachment (id=8984)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8984&action=view)
The test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21800
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-28
17:46 ---
*** This bug has been marked as a duplicate of 19699 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-28
17:46 ---
*** Bug 21800 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-28
17:50 ---
Fixed on the mainline by the moving the warning to right after CFG creation
which is now done for all
functions, even unused ones.
--
What|Removed |Added
--
Looking at PR 21799, I noticed that we accept the code if we remove the second
template function, like
so:
template void f (T &, void (T::*)() );
struct X {
void g() const;
};
const X *x;
int main () {
f (*x, &X::g);
}
--
Summary: Accepts invalid for const member po
--
What|Removed |Added
OtherBugsDependingO||21799
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21801
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-28
17:55 ---
Confirmed, I noticed that we accept the code if we get rid of the second
template function (see PR
21801) so in GCC's mind it is ambiguous.
--
What|Removed |Added
-
--
What|Removed |Added
Last reconfirmed|2005-05-11 14:06:29 |2005-05-28 17:59:10
date||
Target Milestone|4.0.1
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-28
18:00 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From ziga at gcc dot gnu dot org 2005-05-28 18:06
---
Confirmed. This regular expression makes use of possessive quantifiers (?+, *+,
++, {n,m}+), which gnu.regexp doesn't support currently. I've written some
Mauve test cases[1] for possessive quantifiers and wi
The following program should compile (and does on recently EDG-base compilers),
because the operator== is build when the template is parsed (it is
non-dependent). However, GCC looks up the == operator at instantiation time and
finds the second, incorrect definition of operator==. This is similar to
--- Additional Comments From ziga at gcc dot gnu dot org 2005-05-28 20:55
---
Proposed patch:
http://thread.gmane.org/gmane.comp.java.classpath.patches/2416
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20435
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-28
21:57 ---
Subject: Bug 19495
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-28 21:57:03
Modified files:
libstdc++-v3 : ChangeLog
libstdc++-v3/inclu
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-28
22:27 ---
Subject: Bug 21562
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-28 22:27:04
Modified files:
gcc: ChangeLog cfgexpand.c
gcc/te
.mib
nop 0
mov r37 = r0
br.call.sptk.many b0 = exit#
;;
break.f 0
;;
.endp foo#
.common inbuf#,8,8
.common outbuf#,8,8
.ident "GCC: (GNU) 4.1.0 20050528 (experimental)"
Notice this incredibly charming predi
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-29
00:02 ---
The resulting code is much better with --param min-crossjump-insns=1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21803
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29
00:16 ---
Subject: Bug 21340
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-29 00:16:05
Modified files:
gcc/cp : ChangeLog method.c
gcc/tests
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29
00:17 ---
Subject: Bug 21340
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-29 00:17:34
Modified files:
gcc/cp : Change
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-29
00:20 ---
Fixed in 4.0.1.
--
What|Removed |Added
Status|ASSIGNED|RESO
--- Additional Comments From gerrit at gcc dot gnu dot org 2005-05-29
02:09 ---
(In reply to comment #29)
> *** Bug 21793 has been marked as a duplicate of this bug. ***
The same example works with the MinGW version of gcj-3.4.2?
And it works when I set the encoding to ISO-8859-1:
$ /
--- Additional Comments From gerrit at gcc dot gnu dot org 2005-05-29
02:25 ---
No longer a problem with gcc-3.4.2.
--
What|Removed |Added
Status|NEW
The source file has the line
if (gethostname(host,sizeof host) == -1) return -1;
Compiled without optimization:
$ ~/gcc34x/bin/gcc -S -c -o - x.i | grep -A2 hostname
callgethostname
cmpl$-1, %eax
jne .L46
Compiled with -O2:
callgethostname
--- Additional Comments From rick-gcc at frob dot com dot au 2005-05-29
03:22 ---
Created an attachment (id=8985)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8985&action=view)
Preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21804
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-29
04:07 ---
Kriang --
I think this is due to your friend class lookup changes. Would you please
investigate?
-- Mark
--
What|Removed |Added
--
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org |
Status|NEW
--
What|Removed |Added
Component|c |rtl-optimization
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29
06:47 ---
Subject: Bug 21639
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-29 06:47:08
Modified files:
gcc: ChangeLog tree-complex.c
Log messag
Following PR21639 (and http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02604.html):
"there are several places in loop opts that are not GGC-safe (in
particular the tree nodes refered from loop structures are not
seen by garbage collector, and I think there are some other instances)."
This PR is an e
46 matches
Mail list logo
