--- Additional Comments From laurent at guerby dot net 2005-02-06 09:50
---
Fixed by last commit
--- Additional Comments From laurent at guerby dot net 2005-02-06 09:57
---
Fixed by last commit
--
What|Removed |Added
--- Additional Comments From laurent at guerby dot net 2005-02-06 10:02
---
(In reply to comment #19)
Nathanel I confirm your small patch (+autoconf) restores Ada cross x86 to
powerpc-rtems build, and I've even been able to powerpc-rtems-gnatmake Ada
examples and run them on gdb psim. I
The attached C++ program triggers an assertion violation when compiled with -O2
(it should not).
The assertion is not triggered when adding -fno-strict-aliasing, or when
removing
-O2. It is also working when slight changes to the program are made (see
comments
in the source). It is the smallest
--- Additional Comments From sylvain dot pion at sophia dot inria dot fr
2005-02-06 10:20 ---
Created an attachment (id=8135)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8135&action=view)
Compile with -O2 and execute
It is not preprocessed, but uses (and for illustration).
I c
--- Additional Comments From aj at gcc dot gnu dot org 2005-02-06 10:27
---
See also http://gcc.gnu.org/ml/gcc/2004-12/msg01142.html
This appears also on x86-64.
--
What|Removed |Added
--
struct H {
operator char();
operator short();
};
int const& ref = H();
output:
oref.cpp:7: error: conversion from 'H' to 'const int' is ambiguous
oref.cpp:4: note: candidates are: H::operator short int()
oref.cpp:3: note: H::operator char()
oref.cpp:7: internal compiler er
--- Additional Comments From giovannibajo at libero dot it 2005-02-06
13:11 ---
So this is both a compiler bug and a v3 bug. HJL provided a patch for the C++
frontend here:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00180.html
Notice that the patch is incomplete because it is missing
Consider:
int
foo (void)
{
return -1;
}
int
bar (void)
{
unsigned int a = 0x;
return a;
}
int
baz (void)
{
int a = -1;
unsigned int b = 0x;
return a == (int) b;
}
Here is what I get:
;; Function foo (foo)
foo ()
{
:
return -1;
}
;; Function bar (bar)
bar ()
{
--- Additional Comments From pcarlini at suse dot de 2005-02-06 13:19
---
A testcase suitably distilled from #11 should do.
For the libstdc++ side of the problem, we are missing a testcase. Probably, it's
better opening a separate, complete libstdc++ PR: then fixing the latter will be
s
Consider:
void abort (void) __attribute__ ((noreturn));
union node
{
int dummy;
union node *ptr;
};
extern void bar (union node *tree);
extern const int global_constant;
void
foo (union node *p)
{
if (global_constant == 1)
abort ();
bar (p->ptr);
if (global_constant == 1)
a
--- Additional Comments From pcarlini at suse dot de 2005-02-06 13:22
---
But, on second thought, sorry, I think we have also a third problem, target
dependent, for R_X86_64_PC32 relocaltions wrongly emitted for global symbols
on x86_64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Additional Comments From pcarlini at suse dot de 2005-02-06 13:24
---
Actually, the testcase in comment #11 is about the *third* issue, AFAICS.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
Consider:
extern void bar (int);
foo (int *array)
{
int i;
for (i = 0; i <= 10; i++)
{
bar (i + 1);
array[i / ((unsigned) 32)] |= ((unsigned long) 1) << (i % ((unsigned)
(32)));
}
}
The last tree SSA dump looks like so:
foo (array)
{
unsigned int D.1154;
unsigned i
Consider:
extern void abort (void) __attribute__ ((__noreturn__));
extern int bar (int, int);
int
foo (int mode, int size, unsigned int align)
{
int align0;
int iftmp1;
if (mode == 0)
{
if (align != 128)
abort ();
}
align0 = (int) align;
if (mode == 0)
{
Consider:
extern unsigned char size_lookup[257];
int
foo (unsigned int t)
{
return (size_lookup [(int) t] == size_lookup[t]);
}
int
bar (unsigned int t)
{
int a = t;
return a == t;
}
Both functions should return 1, and in fact that's what the RTL optimizers
notice, but the tree optimizers
--
What|Removed |Added
CC||stevenb at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19790
--
What|Removed |Added
CC||stevenb at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19792
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-06
15:04 ---
Can you see if global_constant is marked call-clobbered, or alias global_var?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19789
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-06
15:19 ---
Confirmed, I think is a regression (even though it does not show up with
checking).
--
What|Removed |Added
--
--
What|Removed |Added
Attachment #8135|application/octet-stream|text/plain
mime type||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19786
testing due to a bug report i got about not being able to file new bugs.
--
Summary: testing pr
Product: gcc
Version: 2.95
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: bootstrap
AssignedTo: unassigne
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-06
15:29 ---
Hmm, interesting. On PPC I need -O3. What is more interesting is that I could
not see where the
problems were in the tree dumps, therfor I am moving this into the rtl
optimization component. It
might
--
What|Removed |Added
OtherBugsDependingO||19721
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19788
--
What|Removed |Added
OtherBugsDependingO||19721
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19791
--
What|Removed |Added
OtherBugsDependingO||19721
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19789
--
What|Removed |Added
OtherBugsDependingO||19721
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19790
--
What|Removed |Added
OtherBugsDependingO||19721
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19792
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-02-06
15:53 ---
Person having trouble has confirmed it is fixed now
--
What|Removed |Added
Statu
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-06
16:04 ---
All compilers were bootstrapped, with the following flags:
"--disable-{nls,checking} --enable-languages=c,c++"
Below, gcc40 is CVS HEAD. This was on a 1.6GHz Opteron, with -m32.
The machine has 4GB of
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-06
16:04 ---
Confirmed. The problem is from TREE_OVERFLOW/TREE_CONSTANT_OVERFLOW.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-06
16:12 ---
Confirmed but guess what my tree combiner fixes the problem:
# i_24 = PHI ;
:;
D.1165_26 = (unsigned int) i_24;
D.1166_25 = D.1165_26 + 1;
i_9 = (int) D.1166_25;
bar (i_9);
D.1121_5 = D.1165_26 >
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-06
16:17 ---
Confirmed, For bar, my tree combiner fixes the missed optimization.
Not for foo.
--
What|Removed |Added
--
--- Additional Comments From hjl at lucon dot org 2005-02-06 16:23 ---
I don't think emitting R_X86_64_PC32 is a bug since
-fvisibility=hidden -fvisibility-inlines-hidden is
used and the undefined function can be defined in
another .o file. The real bug is gcc doesn't emit
.hidden f
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-06
16:25 ---
Confirmed.
--
What|Removed |Added
CC||pinskia at
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-06
16:26 ---
Confirmed.
--
What|Removed |Added
CC||pinskia at
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-06
16:49 ---
Similar numbers on a 1.4GHz Xeon (i686):
gcc32 gcc33 gcc34 gcc40
-O0 18.865s 15.107s 13.286s 10.193s
-O1 33.511s 30.096s 24.693s 23.543s
-O2 46.527s 42.657s 42.618s 33.549s
-O
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-06
16:54 ---
Considering the numbers from #44, #48, and #49, I think we can conclude
that we are back to the compile times GCC 3.0 used to have. It should
be noted that we have a significantly larger memory foot print
--- Additional Comments From schlie at comcast dot net 2005-02-06 17:14
---
(In reply to comment #1)
- as I'm curious as to what the "proper" interpretation/handling of
target dependant constant value casts should be; it seems that in
the provided example, the optimized transformati
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-06
17:17 ---
(In reply to comment #2)
> (In reply to comment #1)
Really TREE_OVERFLOW/TREE_CONSTANT_OVERFLOW should go away, there has been some
talk about
removing them. on the tree level, having that flag set we rea
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-06
17:41 ---
Arguably, PR16961 is not directly related. But if we fix that bug and the
similar "long long" issues on 32 bits hosts, then the "64 bits arith on 32
bits hosts" thing should be a non-issue (assuming the tr
--- Additional Comments From kazu at cs dot umass dot edu 2005-02-06 17:49
---
Hi Richard,
I didn't say that load elimination is the *only* way to take this
optimization opportunity.
DOM *can* thread incoming edges to a basic block with more than COND_EXPR
or SWITCH_EXPR in limited cir
Please make jump threading related bugs block this meta bug.
--
Summary: [meta-bug] Jump threading related bugs
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: meta-bug
Severity: enhancement
Priority: P2
--
What|Removed |Added
BugsThisDependsOn||15352
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
--
What|Removed |Added
BugsThisDependsOn||16538
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
--
What|Removed |Added
BugsThisDependsOn||17116
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
--
What|Removed |Added
BugsThisDependsOn||18046
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
--
What|Removed |Added
BugsThisDependsOn||18076
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
--
What|Removed |Added
BugsThisDependsOn||18832
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
--
What|Removed |Added
BugsThisDependsOn||19516
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Status|UNCONFIRMED
--- Additional Comments From kazu at cs dot umass dot edu 2005-02-06 18:08
---
Yes, global_constant is considered call clobbered.
Here is the full dump of .t18.alias1.
;; Function foo (foo)
foo: Total number of aliased vops: 1
Referenced variables in foo: 5
Variable: global_constant
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-02-06 18:08
---
If you want to compare how the memory footprint has affected performance, use
these flags in 3.3 and later:
--param ggc-min-expand=30 --param ggc-min-heapsize=4096
Those are the hardcoded values that 3.2 us
--- Additional Comments From sgk at troutmask dot apl dot washington dot
edu 2005-02-06 18:12 ---
An updated patch that does not have the regression is here
http://gcc.gnu.org/ml/fortran/2005-02/msg00039.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19754
The attached C++ program triggers an assertion violation when compiled with -O2
(it should not).
The assertion is not triggered when adding -fno-strict-aliasing, or when
removing
-O2. It is also working when slight changes to the program are made (see
comments
in the source). It is the smallest
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-06
18:34 ---
*** Bug 19785 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19786
The attached C++ program triggers an assertion violation when compiled with -O2
(it should not).
The assertion is not triggered when adding -fno-strict-aliasing, or when
removing
-O2. It is also working when slight changes to the program are made (see
comments
in the source). It is the smallest
The attached C++ program triggers an assertion violation when compiled with -O2
(it should not).
The assertion is not triggered when adding -fno-strict-aliasing, or when
removing
-O2. It is also working when slight changes to the program are made (see
comments
in the source). It is the smallest
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-06
18:34 ---
*** Bug 19784 has been marked as a duplicate of this bug. ***
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-06
18:34 ---
*** Bug 19783 has been marked as a duplicate of this b
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-06
18:35 ---
*** Bug 19782 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19786
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-06
18:34 ---
*** Bug 19784 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19786
The attached C++ program triggers an assertion violation when compiled with -O2
(it should not).
The assertion is not triggered when adding -fno-strict-aliasing, or when
removing
-O2. It is also working when slight changes to the program are made (see
comments
in the source). It is the smallest
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-06
18:38 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--
What|Removed |Added
Keywords||rejects-valid
Last reconfirmed|2004-11-06 16:09:59 |2005-02-06 18:44:13
date|
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-02-06 18:46
---
Does your version of expect include the patch in bug 12096? If not, and
if using a version with that patch fixes your problem, then this would be
a duplicate of that bug.
--
What|Removed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-06
18:47 ---
Subject: Bug 18219
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-06 18:47:14
Modified files:
gcc: ChangeLog tree-ssa-loop-ivopts.c
Lo
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-02-06
18:51 ---
This dump shows a number of problems.
For starters, global_constant should not be call clobbered.
This is something diego should look at.
--
What|Removed |Added
If such a mechanism existed, asm programs would able to be structured to
honor their declaration as such; thereby enable implementations of set/longjump
to exclude them from being otherwise improperly save/restored, for example, etc.
--
Summary: GCC needs mechanism to expose compile-ti
--
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19795
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-06
19:37 ---
Subject: Bug 7549
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-06 19:37:25
Modified files:
gcc: ChangeLog
gcc/doc: in
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-06
19:42 ---
Fixed in 4.0.0.
--
What|Removed |Added
Status|NEW |RESOL
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-02-06
20:25 ---
Updated version of the patch:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00205.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17790
--- Additional Comments From andrewhutchinson at cox dot net 2005-02-06
23:06 ---
Taking X as the initial value of x on function entry.
The loop is defined as i=X to 0, step -1. Which is a simple do loop.
It gets "optimized" as i=0 to -X, step -1. (Which is something bizarre!)
The cod
My mips-sgi-irix6.5 bootstraps have been failing since 25 Jan. (I have been
travelling and didn't notice).
- The last successful build was 2005-01-24 09:07 UTC
- First failure was approx 2005-01-25 09:00 UTX
I suspect that the problem is due to:
2005-01-24 Richard Sandiford <[EMAIL PROTECTED
The test g++.dg/abi/inline1.C scan-assembler-not _ZTV1S
fails on hppa{2.0w,64}-hp-hpux11.{11,23}. This is a regression
from 3.4.x.
--
Summary: [4.0 Regression] g++.dg/abi/inline1.C fails on hppa*-*-
hpux*
Product: gcc
Version: 4.0.0
A program as simple as:
int b = 10;
int a;
a = (++b) + (++b) + (++b);
printf("%d", a);
shows the wrong answer.
It should be 36, it shows 37. Optimisations on or off throw the same result.
Source of the problem: Generated code.
Pseudo C/asm code:
++b;
++b;
%eax = b;
%edx = b;
%edx += %ea
The tests gcc.dg/sibcall-3.c and gcc.dg/sibcall-4.c (execution tests)
fail on hppa64-hp-hpux11.{11,23}. Not a regression relative to 3.4.x.
--
Summary: sibcall-3.c and sibcall-4.c fail on hppa64-*-hpux*
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
--- Additional Comments From pcarlini at suse dot de 2005-02-07 00:19
---
*** This bug has been marked as a duplicate of 11751 ***
--
What|Removed |Added
Statu
--- Additional Comments From pcarlini at suse dot de 2005-02-07 00:19
---
*** Bug 19798 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-02-07 01:02
---
I see no reason we'd ever want to carry the deprecation of the -W name
through to removing it or making it warn that it is deprecated; synonyms
for warning options don't cause any implementation problems or co
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-07
01:10 ---
Subject: Bug 14402
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-07 01:10:14
Modified files:
gcc: ChangeLog
gcc/doc: i
With LAST_UPDATED: "Mon Feb 7 00:40:47 UTC 2005" I get:
/home/hp/combined/mmixware-sim/gcc/xgcc -B/home/hp/combined/mmixware-sim/gcc/
-nostdinc -B/home/hp/combined/mmixware-sim/mmix-knu\
th-mmixware/gnuabi/newlib/ -isystem
/home/hp/combined/mmixware-sim/mmix-knuth-mmixware/gnuabi/newlib/targ-inclu
--
What|Removed |Added
Summary|mmix-knuth-mmixware broken |[regression 4.0] mmix-knuth-
||mmixware broken
http://gcc.gnu.o
cppinternals.texi refers to old file names cpphash.h, cpplex.c, cppfiles.c.
In 4.0 the files have been renamed.
--
Summary: cppinternals.texi references old file names
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
--- Additional Comments From hp at gcc dot gnu dot org 2005-02-07 01:23
---
Adding CC:s based on the accusation and description in
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00220.html>.
To repeat, build a combined tree for mmix-knuth-mmixware
(simtest-howto.html yadda yadda no simulat
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-07
01:49 ---
(In reply to comment #1)
> Adding CC:s based on the accusation and description in
> http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00220.html>.
> To repeat, build a combined tree for mmix-knuth-mmixware
> (sim
--
What|Removed |Added
CC|pinskia at physics dot uc |pinskia at gcc dot gnu dot
|dot edu |org
http://gcc.gnu.org/bugzilla/sh
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-07
01:52 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-07
01:52 ---
Subject: Bug 17135
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-07 01:52:27
Modified files:
gcc: ChangeLog
gcc/doc: i
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-07
01:54 ---
I want to say this is target bug, because there was a change to move
hppa*-*-hpux* over to weak
symbol support.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19797
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-07
01:58 ---
Hmm, for sibcall-3.c (likewise for 4) we have the following comment:
This test is xfailed on targets without sibcall patterns
(except targets where the test does not work due to the return address
not
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-07
02:04 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-07
02:05 ---
Confirmed.
--
What|Removed |Added
CC||bonzini at
--- Additional Comments From roger at eyesopen dot com 2005-02-07 02:08
---
Untested fix here: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00223.html
HP, could you check whether it fixes mmix-knuth-mixware for you?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19800
testsuite/lib/scanasm.exp:hidden-scan-for returns an empty string
for object formats other than elf and mach-o. This causes any
tests using scan-not-hidden to fail. Instead, they should be
UNRESOLVED when how to test for hidden symbols on that object format
is not known. Likewise, scan-hidden sh
--- Additional Comments From hp at gcc dot gnu dot org 2005-02-07 02:13
---
In reply to comment #3, will do, as soon as that machine is done with
cris-elf testing.
(In the meantime, let me remind that anyone, including you, can check
out a combined tree and try it.)
--
http://gcc.gnu
--- Additional Comments From schlie at comcast dot net 2005-02-07 02:42
---
(In reply to comment #2)
Might it be possible to change the severity to at least "normal"
and possibly reclassify it as a "mis-optimization", as it's very
typical for folks who know processors to intentionally w
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-07
02:46 ---
(In reply to comment #4)
> (In reply to comment #2)
It is minor because it is a missed optimization. (this really is a target
dependent bug in that different
cost matrixes give different answers so it mig
--- Additional Comments From schlie at comcast dot net 2005-02-07 03:01
---
(In reply to comment #5)
> (In reply to comment #4)
Understood, Thanks (apparently it' becomming more important to get the costs
more correct).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19686
gcc version 4.0.0 20050203 (experimental)
The following code snippet shows how branch prediction isnt used even when
specifying builtin_expect. flags used: -O2 -mcpu=power4
#if 1
#define likely(x) __builtin_expect(!!(x), 1)
#else
#define likely(x) x
#endif
int i;
void foo(void)
{
--
What|Removed |Added
BugsThisDependsOn||19804
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
1 - 100 of 124 matches
Mail list logo
