--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-25
05:06 ---
I think this is invalid because the testcase is what I thought it was:
struct dwarf_cie {
int i;
unsigned char augmentation[];
};
int get_cie_encoding (const struct dwarf_cie *cie)
{
cie->a
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-25
04:38 ---
The only time I am thinking this is NULL is when you have something like:
struct a
{
int b[];
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23999
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-25
04:31 ---
Confirmed, on most targets (ppc and x86 at least) this is done at the rtl
level, I don't know why it is not
done for alpha.
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-25
04:28 ---
Invalid then.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVE
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-25
04:25 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-25
04:25 ---
Confirmed.
--
What|Removed |Added
CC||hubicka at
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-25
04:25 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-25
04:24 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-25
04:23 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
Hi,
Whilst this bug has been marked as resolved, I am still experiencing the same
problems (with arts-1.4.91 - the version shipped with KDE 35. Beta 1).
My gcc version info : gcc (GCC) 4.1.0 20050924 (experimental)
The following is the stack dump for the problem
--- Additional Comments From kazu at gcc dot gnu dot org 2005-09-25 02:57
---
By the way, unpatched cc1 propagated 95619 constants while compiling cc1-i
files.
Patched one propagated 96482 constants in the ccp run (that is, not store-ccp).
So there is a 0.9% improvement.
--
http://
--- Additional Comments From kazu at gcc dot gnu dot org 2005-09-24 23:58
---
(In reply to comment #12)
> It takes about 10 minutes to compile attached testcase with -O2 -mcpu=ev4 and
> about 2 minutes for -O2 -mcpu=ev5 (compiled on EV45 233Mhz).
> The difference is in cost of multiply o
--- Additional Comments From hjl at lucon dot org 2005-09-24 23:47 ---
Shouldn't it be re-reverted?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24051
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-24
23:44 ---
Commenting out AC_PROG_CXX should work. It was something which was reverted in
the import.
--
What|Removed |Added
--
This patch
http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00882.html
I got
configure:2432: checking for C++ compiler default output file name
configure:2435: /export/build/gnu/gcc/build-x86_64-linux/./gcc/xgcc
-shared-libgcc -B/export/build/gnu/gcc/build-x86_64-linux/./gcc -nostdinc++
-L/export/build
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-24
23:32 ---
I have a very simple work around. If we could get the eh region from a
label/bb, it would make it
easier.
--
What|Removed |Added
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-24
23:08 ---
I have a patch which dects this earlier and will post it soon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19505
--- Additional Comments From skyhover at hotmail dot com 2005-09-24 22:32
---
Yes, you made me clear now. "dest->lower" points to the same thing as "src-
>lower" after "*dest=*src". So the loop is semantically right, creating copies
of expressions pointed to by "src->lower".
On the ot
--- Additional Comments From bakgab at vnet dot hu 2005-09-24 22:24 ---
Tested on Debian Sarge with g++-3.3 and g++-3.4.
The former has no problem, but the latter fails to link.
Another man reported to fail (the root problem) on Fedora Core 3. (gcc 3.4 too)
--
http://gcc.gnu.org/bugzi
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-24
22:15 ---
Confirmed, only a 3.4 regression.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From bakgab at vnet dot hu 2005-09-24 22:14 ---
Created an attachment (id=9802)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9802&action=view)
Output of g++-3.4 --version and g++-3.4 -o test test.cpp
Output of
g++-3.4 --version
and
g++-3.4 -o test test.cpp
--- Additional Comments From bakgab at vnet dot hu 2005-09-24 22:09 ---
Created an attachment (id=9801)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9801&action=view)
A test file that fails to link.
A test file that shows the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
When trying to create a template using a specialized form inside in a static
class it fails to link.
Ex.:
template struct StaticClass
{
static void ret() {}
};
template
void func(void function()) {}
template struct Test
{
void doIt()
{
func(StaticClass >::r
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-24
21:31 ---
One more thing, is that this happens only at -O2 and above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19505
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-24
21:31 ---
The problem shows up only in .final_cleanup.
Before:
Eh tree:
4 catch tree_label:
3 try
2 catch tree_label:
1 try
After:
4 catch tree_label:*LJpc=2041
3 try
2 catch tree_label:*LJpc=204
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-24
20:59 ---
Only the following:
if (TREE_CODE_CLASS (TREE_CODE (scope)) != tcc_type)
Should be:
if (!TYPE_P (scope))
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22172
--- Additional Comments From phython at gcc dot gnu dot org 2005-09-24
20:44 ---
Created an attachment (id=9800)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9800&action=view)
We should give the user an error message
Anyone have a better error message?
--
What|R
Hi,
I'm not sure if it is a bug, but I couldn't find a justification for
this behaviour at http://www.open-std.org/jtc1/sc22/open/n2356/.
gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
AMD Athlon(tm) XP 2600+, GNU/Linux (Red Hat Linux 8)
To reproduce (`test.cpp' is attached):
$ g++ test.cpp -
--- Additional Comments From tsv at solvo dot ru 2005-09-24 20:29 ---
It takes about 10 minutes to compile attached testcase with -O2 -mcpu=ev4 and
about 2 minutes for -O2 -mcpu=ev5 (compiled on EV45 233Mhz).
The difference is in cost of multiply op - 100 for ev4 and about 54 for ev5.
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-24
20:12 ---
This is a very recent regression as it worked with 20050908.
I think it was caused by:
2005-09-17 Richard Henderson <[EMAIL PROTECTED]>
* tree-pass.h, tree-flow.h, tree-ssa-dce.c: Revert last chan
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-24
20:09 ---
Confirmed, reduced testcase:
int DES_CBCUpdate(unsigned char * output, int len)
{
int work[2];
unsigned int i;
for(i = 0;i < len/8;i++)
unscrunch (&output[8*i], work);
}
Only "-O1 -ftree-vectoriz
--- Additional Comments From harold at alum dot mit dot edu 2005-09-24
20:07 ---
I know that I should really only compile with such aggressive options for the
most compute-intensive modules, in order to avoid these sorts of issues, but I
thought you would appreciate the bugs in advance
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-24
20:00 ---
Oh, I had missed the -g but that really should not matter. Anyways it does not
with "--param ggc-
min-heapsize=0 --param ggc-min-expand=0" which means this is a GC problem.
--
http://gcc.gnu.org/bugzil
--
What|Removed |Added
Component|c++ |middle-end
Keywords||GC, ice-on-valid-code
http://gcc.gnu.org/bugzilla/
--- Additional Comments From harold at alum dot mit dot edu 2005-09-24
19:06 ---
[EMAIL PROTECTED] /tmp $ gcc-4.1 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.1/configure --program-suffix=-4.1 --disable-multilib
--enable-languages=c,c++
Thread model
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-24
17:47 ---
The option is now -fdump-tree-tu.
--
What|Removed |Added
Summary|-fdump-tree-orig
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-24
17:42 ---
Hmm, the easy way to to have a pass which finds all the atexit calls and sees
if the function which is
passed is a const function and if it is, then just remove the atexit call.
--
What|Re
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-24 17:42
---
To add to FX's eplanation, I know libm on at least {Net,Open,Free}BSD do not
have a complete set of C99 long double functions (e.g., logl). We
need to map logl to log with a note in gfortran.info that the int
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-24
17:38 ---
On the mainline we get:
_ZN5foo_tIfE7bar_refEff:
.LFB661:
ucomiss 4(%rdi), %xmm1
leaq-8(%rsp), %rdx
leaq4(%rdi), %rax
movss %xmm0, -4(%rsp)
movss %xmm1, -8
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-24
17:18 ---
Confirmed. I somehow missed this.
--
What|Removed |Added
Status|UNCONFIRMED
--
What|Removed |Added
Keywords||documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21629
--
What|Removed |Added
Component|other |ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21629
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-24
17:11 ---
Works just fine for me on the mainline so closing as fixed.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-24
16:59 ---
The vector intrinsics is only thing left really since we do support the
autovectorizer on ia64.
--
What|Removed |Added
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-24
16:55 ---
This is a glibc issue and nothing else.
Closing as invalid.
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org |org
URL|
--- Additional Comments From gerald at pfeifer dot com 2005-09-24 16:34
---
Historically, on some systems one had to define _POSIX_C_SOURCE to get at
fileno(), which has been used by code generated by flex() and probably others.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24012
--
What|Removed |Added
CC||spop at gcc dot gnu dot org
Last reconfirmed|2005-07-07 07:47:46 |2005-09-24 16:25:06
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-24
16:22 ---
Changing the summary to be more reflect what this bug is about.
--
What|Removed |Added
OtherB
--
What|Removed |Added
BugsThisDependsOn||9463
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21267
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-24
15:49 ---
Can you give the output of "gcc-4.1 -v"?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24049
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-24
15:47 ---
*** Bug 24048 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-24
15:46 ---
*** This bug has been marked as a duplicate of 23589 ***
--
What|Removed |Added
--- Additional Comments From Woebbeking at web dot de 2005-09-24 14:44
---
Hi,
I already thought that is the same as with KDE's artsd but it still crashes for
me (since GCC 4.0.0):
#0 0xb7857b5e in __gnu_cxx::__pool::_M_reclaim_block ()
from /usr/lib/libstdc++.so.6
#
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-24
14:15 ---
I believe the gfc_copy_array_spec() function is correct. Its purpose is to
allocate memory for the dest gfc_array_spec. It then copies all fields of src
into dest (Steve: copying pointers would be "dest =
--- Additional Comments From harold at alum dot mit dot edu 2005-09-24
14:04 ---
Created an attachment (id=9799)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9799&action=view)
Segfaults on compilation.gcc-4.1 -DHAVE_CONFIG_H -D__NO_CTYPE -O3
-DPROTOTYPES=0 -DUSE_ANSI=1 -DAMD64 -O3
The attached preprocessed file segfaults during compilation with the compile
line:
gcc-4.1 -DHAVE_CONFIG_H -D__NO_CTYPE -O3 -DPROTOTYPES=0 -DUSE_ANSI=1 -DAMD64 -O3
-ffast-math -funroll-all-loops -fpeel-loops -ftracer -funswitch-loops
-ftree-vectorize -march=k8 -g -pthread -MT desc.o -MD -MP -MF "
g++ crashes when compiling following code:
class __declspec(dllimport) BaseClass {
public:
virtual ~BaseClass();
};
class __declspec(dllimport) SubClass : public BaseClass
{
public:
// Ctor
SubClass(){}
};
BaseClass::~BaseClass()
{
//do nothing
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-24
13:14 ---
The list of warnings is not that long any more:
../../../gcc/libgfortran/io/list_read.c: In function 'list_formatted_read':
../../../gcc/libgfortran/io/list_read.c:1289: warning: argument 'len' might be
c
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-24
12:56 ---
I don't have access to that mips-sgi-irix6.5 computer anymore, and since nobody
every confirmed this (and there are regular mips-sgi-irix6.5 successful reports
posted to gcc-testresults), this bug is close
--- Additional Comments From falk at debian dot org 2005-09-24 09:39
---
(In reply to comment #21)
> There have been lots of messages exchanged on this topic. It was just
> pointed to me that the C++ standard -- unlike the C99 standard -- has the
> following wording 5.7/7:
Hmm, I miss
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org |org
Status|UNCONFIRME
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-24
08:55 ---
Subject: Bug 23802
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-24 08:55:38
Modified files:
libgfortran: ChangeLog
libgfortran/intrin
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-24
08:39 ---
Subject: Bug 23380
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-24 08:39:35
Modified files:
libgfortran: ChangeLog
libgfortran/intrin
--- Additional Comments From amodra at bigpond dot net dot au 2005-09-24
08:03 ---
Affects powerpc-linux too.
--
What|Removed |Added
GCC target triplet|powerpc-darwin
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-24
07:57 ---
It's a work in progress, and I guess that it will stay open for a long time.
Right now, we have medium front-end support and bad library support for large
kinds. I have a patch that is half-accepted (by St
67 matches
Mail list logo
