--- Additional Comments From appfault at hotmail dot com 2005-09-12 06:17
---
I agree that gcc apparently complies with the standard as currently
implemented. So this zilla is not a defect, but an enhancement request.
Why not reopen this to add a -Wundefined-behavior, so that at least
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-12
06:14 ---
Investigating.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ebo
--- Additional Comments From jvdelisle at verizon dot net 2005-09-12 05:39
---
I have confirmed that the test case given is resolved by the patch discusssed in
comment #3. The patch is in review.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23379
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-12
05:01 ---
For 4.1 we do have IPA based constant propagation which basically implements
what you want.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23830
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Component|c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-12
04:49 ---
Subject: Bug 19265
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-12 04:49:11
Modified files:
libstdc++-v3 : ChangeLog
libstdc++-v3/confi
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-12
04:49 ---
Subject: Bug 22309
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-12 04:49:11
Modified files:
libstdc++-v3 : ChangeLog
libstdc++-v3/confi
subj: For functions specified inline, decision to inline them should be based on
inlined code size instead of un-inlined function length.
Here is a simple snippet of a larger complex.
inline int changePrecision(int x, int x_prec, int y_prec) {
if (y_prec>x_prec) return (x<<(y_prec-x_prec));
else
--- Additional Comments From igodard at pacbell dot net 2005-09-12 03:17
---
In the case you give I count one template argument specificatiob, and two
template parameters.
As for a better message, how about: "A template definition must have same number
of formal template specifications
--- Additional Comments From rrr6399 at futuretek dot com 2005-09-12 02:20
---
FYI: Here's what Intel did for to address the record sizes larger than 2 GB:
http://www.intel.com/software/products/compilers/flin/docs/main_for/mergedProjects/bldaps_for/format_of_record_types_.htm
The nice
--
What|Removed |Added
Component|java|libgcj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23829
--- Additional Comments From bangerth at dealii dot org 2005-09-12 01:55
---
Well, but then tell me what you expect for the case you have:
template
voidfoo::g() {}
How many template parameters do you give? I count one (in the
'template <...>' angle brackets). And how man
--- Additional Comments From chat95 at mac dot com 2005-09-12 01:54 ---
Created an attachment (id=9708)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9708&action=view)
FreeBSD >=5.3 has -lpthread
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23829
FreeBSD 5 has -lpthread but not activated.
--
Summary: FreeBSD 5 support for libjava
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gn
--
What|Removed |Added
Component|rtl-optimization|middle-end
Keywords||missed-optimization
http://gcc.gnu.org/bugzilla/sh
When compiling the files in the attachment for PR22574 using the command line:
gcc -fwhole-program --combine -march=i686 -O2 button.i charproc.i charsets.i
cursor.i data.i doublechr.i fontutils.i input.i main.i menu.i misc.i print.i
ptydata.i screen.i scrollbar.i tabs.i util.i xstrings.i VTPrsTbl.
--
What|Removed |Added
Known to fail||3.4.5
Known to work||3.4.4
Summary|[3.4.5 regression] rejects |[3
--- Additional Comments From bangerth at dealii dot org 2005-09-12 01:18
---
Folks,
I find that this bug is now present on the 3.4.x branch. I don't know
for how long, but believe that it broke somewhere between 5 and 15 days
ago. It would be good if we could fix this before 3.4
--
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2003-11-22 20:18:21 |2005-09-12 01:18:36
date|
--- Additional Comments From igodard at pacbell dot net 2005-09-12 01:14
---
Well, you may think it's clear but I am am counter-example :-) Perhaps
"template parameter" (in the message) is a formal term in the language syntax
specification (who but acompiler maven would know that?), but
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-12 00:35
---
(In reply to comment #7)
>
> I realize that disagreeing with the assumptions made during the design may be
> regarded by some as "rants", but what I was attempting to do (perhaps poorly)
> is
> illustrate wh
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-12
00:32 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
Standard C++ does not include hexadecimal floating point numbers. The
preprocessor correctly pedwarns for C++ if such a preprocessing token is
converted to a token, but it incorrectly allows p+ and p- in preprocessing
tokens in standard C++ mode in the first place. The problem is probably the
ta
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-11
23:46 ---
For the reporter: what the compiler is telling you is that your code is not
valid ISO C++. What it is not telling you is that G++ 3.3.4 did not really
actually know what is valid C++ and what is not.
In
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11
23:39 ---
(In reply to comment #0)
> The following code compiled in g++ 3.3.4, but does not compile in the latest
> 4.0.x
> Seems like a regression testing oversight.
Nope, see below.
> The error is
> error: inval
--- Additional Comments From bangerth at dealii dot org 2005-09-11 23:38
---
The code is illegal (you can only partially specialize class templates,
not function templates). I think the error message is clear: you only
give one template parameter (and try, illegally, to fix the other),
--- Additional Comments From cvs-commit at developer dot classpath dot org
2005-09-11 23:36 ---
Subject: Bug 21418
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch:
Changes by: Mark Wielaard <[EMAIL PROTECTED]> 05/09/11 23:15:58
Modified files:
The following code compiled in g++ 3.3.4, but does not compile in the latest
4.0.x
Seems like a regression testing oversight.
template
class db_reference {
private:
T r;
public:
ID_TYPE &id;
db_reference(ID_TYPE req_id=0);
T &get();
std::string print(int full_subtables
--- Additional Comments From rrr6399 at futuretek dot com 2005-09-11 23:22
---
I'm not sure why I'm getting so much pushback on this silly thing.
I realize that disagreeing with the assumptions made during the design may be
regarded by some as "rants", but what I was attempting to do (p
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-11
23:22 ---
Subject: Bug 23098
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-11 23:22:11
Modified files:
gcc: ChangeLog
gcc/config/rs6000:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11
23:02 ---
See http://gcc.gnu.org/ml/gcc-regression/2005-09/msg00022.html
--
What|Removed |Added
Targ
Starting from
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00497.html
there are extra C++ failures:
FAIL: g++.dg/other/error8.C (test for errors, line 8)
FAIL: g++.dg/other/error8.C (test for errors, line 9)
FAIL: g++.dg/other/error8.C duplicate error messages (test for bogus messages,
lin
--- Additional Comments From mark at gcc dot gnu dot org 2005-09-11 22:29
---
And I tracked our problems with The javax.swing.Box inner class AccessibleBox
extends AccessibleAWTContainer in GNU Classpath to a similar order problem.
Take the following source files:
p/AClass.java
:::
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-11 22:05
---
(In reply to comment #5)
>
> Furthermore, when one writes binary in C, you get exactly what your variables
> are sized to in your code. If the platform is a 32 bit machine and is IEEE
> compliant,
What happe
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-11
22:01 ---
Aren't these fixed? Trying to compile these testcases with an up-to-date
compiler, I don't get ICEs...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20971
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-11
21:51 ---
Are you sure about that, Thomas? Most compilers I have access to (Intel, g95,
g77, Sun, Lahey) says something similar to "The left and right hand sides of
this array syntax assignment must be conformable a
--
What|Removed |Added
Target Milestone|4.0.1 |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19872
--- Additional Comments From sebor at roguewave dot com 2005-09-11 21:34
---
In reply to comment #6:
The vanilla EDG eccp 3.5 compiles the test case w/o an error:
$ eccp -v t.cpp && ./a.out; echo $?
Edison Design Group C/C++ Front End, version 3.5 (Nov 9 2004 20:00:33)
Copyright 1988-2
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-11
21:27 ---
This is a front-end bug. We generate wrong code for all the ioparm members that
are passed by reference (the pointers are cast, instead of creating
temporaries). All cases handled by set_parameter_ref (in
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot
|dot org |org
URL|
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot
|dot org |org
URL|
--- Additional Comments From rrr6399 at futuretek dot com 2005-09-11 20:47
---
Well, just to warn you, you're going to have a lot of steamed engineers on your
hands when they discover that they either have to recompile all of their FORTRAN
codes on every platform with gfortran, write all
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-11
19:39 ---
Subject: Bug 19872
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-11 19:39:35
Modified files:
gcc/testsuite : ChangeLog
Added files:
gcc/t
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-11
18:55 ---
Subject: Bug 20179
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-11 18:55:16
Modified files:
gcc/testsuite : Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-11
18:55 ---
Subject: Bug 19872
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-11 18:55:16
Modified files:
gcc/testsuite : Change
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-11
18:40 ---
Patch was never committed to 4.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19872
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-11 16:28
---
(In reply to comment #22)
A thoroughly reduced testcase is:
module foo
INTEGER :: i
end module foo
module bar
contains
subroutine sub(j)
use foo
integer, dimension(i) :: j !change dimension to expl
--
What|Removed |Added
Component|c |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23824
extern void * memcpy(void *, void *, int );
int test(char *from, char *to)
{
memcpy(from,to,8);
}
Compilation:
mipsel-linux-gnu-gcc -O2 -EB -o test.o -c test.c
Gives output:
:
0: 88a20003lwl v0,3(a1)
4: 88a30007lwl v1,7(a1)
8: 98a2
You wrote:
:Synopsis: compile short program to get internal compilation error
:
:State-Changed-From-To: open->feedback
:State-Changed-By: paolo
:State-Changed-When: Sat Nov 2 17:23:38 2002
:State-Changed-Why:
:Unfortunately the files didn't reach us. Could you possibly
:send them again?
:
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-11
15:58 ---
Even shorter testcase:
struct A { typedef int X; };
int i = typename A::X();
--
What|Removed |Added
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-11
15:55 ---
Even shorter testcase:
===
struct A;
void foo(A& a)
{
a();
}
===
--
What|Removed |Added
--
--- Additional Comments From igodard at pacbell dot net 2005-09-11 15:44
---
Nah, tried:
struct foo {
template
voidf();
template
voidg();
};
template<>
voidfoo::f() {}
template<>
voidfoo::f() {}
template
voidfoo::g() {}
template
voidfoo::g()
--- Additional Comments From pinskia at physics dot uc dot edu 2005-09-11
15:40 ---
Subject: Re: [4.0/4.1 Regression] OpenBSD's zic.c causes g++ but not gcc to
segfault
On Sep 10, 2005, at 4:34 PM, geoffk at geoffk dot org wrote:
> You should be able to tell if the user set the name
On Sep 10, 2005, at 4:34 PM, geoffk at geoffk dot org wrote:
You should be able to tell if the user set the name because it will
start with a '*'.
Except currently, we do:
else if (C_DECL_REGISTER (decl))
change_decl_assembler_name (decl, get_identifier (asmspec));
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-09-11
15:35 ---
Smaller testcase:
int b;
void foo1 (int);
void foo (void)
{
int i, j, k, l;
short v;
for (i = 0; i < 10; i ++)
{
for (l = 0; l < 10; l++)
{
asm volatile ("\n" : "=a" (v));
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11
15:23 ---
This is after complete unrolling.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23817
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11
15:19 ---
It is not just DOM on the mainline, it is also VRP
--
What|Removed |Added
Summary
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11
15:16 ---
Confirmed a regression.
The mainline and 4.0.0 on PPC gives:
L3:
addi r9,r9,1
bdz L10
L2:
slwi r0,r9,2
lwzx r2,r11,r0
cmpw cr7,r2,r9
beq+ cr7,L3
While 3.3 giv
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11
15:10 ---
Confirmed, a 4.1 regression.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11
14:46 ---
(In reply to comment #0)
> foo.cc:13: error: partial specialization `g' of function template
> foo.cc:13: error: got 1 template parameters for `void foo::g()'
> foo.cc:13: error: but 2 required
No, there
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11
14:42 ---
Confirmed but not a regression.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11
14:38 ---
Confirmed, it is ICE while doing std args which is also new for 4.1.0.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11
14:36 ---
Note this is only reproducible on x86_64 because of the way var_args are
implemented.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11
14:34 ---
(In reply to comment #12)
> Invalid? So whenever behavior is undefined by the C standard, would it be ok
> to delete the user's harddrive as well? This is ridiculous - fix the bug.
It is undefined which
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11
14:31 ---
Confirmed a regression.
--
What|Removed |Added
CC|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11
14:30 ---
This is a target bug as the tree optimizers get it right:
MEM[base: vect_p.55, index: D.1801] = VEC_COND_EXPR < vect_var_.40 >
vect_var_.47 , vect_var_.40
, vect_var_.47 > ;
--
http://gcc.gnu.org/b
--
What|Removed |Added
Component|tree-optimization |target
Keywords||ssemmx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=238
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11
14:27 ---
*** Bug 23814 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11
14:27 ---
More than that this is a dup of bug 19303. unformatted was never supposed to
be used with different
versions of the compiler, or across different targets. It is just like using
write in C.
*** This bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11
14:24 ---
This is the same issue as PR 23812. GCC's RA likes to keep double sized
variables in registers next to
one another.
This is the normal subreg problem with the current RA. There are a couple
other bugs
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11
14:22 ---
This is the normal subreg problem with the current RA. There are a couple
other bugs about this
already opened.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11
14:18 ---
Target bug and not related to the C front-end at all.
--
What|Removed |Added
Compon
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-11
13:35 ---
Subject: Bug 20179
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-11 13:34:57
Modified files:
libgfortran: ChangeLog
libgfortran/io : i
struct foo {
template
voidf();
template
voidg();
};
template<>
voidfoo::f() {}
template<>
voidfoo::f() {}
template
voidfoo::g() {}
template
voidfoo::g() {}
gets you:
~/ootbc/members/src$ g++ foo.cc
foo.cc:13: error: partial specialization `g' of funct
--- Additional Comments From rrr6399 at futuretek dot com 2005-09-11 13:24
---
I believe it really is critical since myself and many others who may use
gfortran need to interoperate with data generated by legacy codes on the same
system that were compiled with g77 or on other systems (Su
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-09-11
12:09 ---
Bud Davis is back and working on the pluggable record markers patch. Expect it
to be completed and committed within a few weeks.
There is no simple solution that is right for all situations. Gfortran uses
64
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-09-11
11:15 ---
The patch from #5 has been committed to mainline, so now we lose to g77 only by
a factor of 30 and not 500 in case the file exists.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23363
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-09-11
11:10 ---
The patch from #12 has been committed to mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21820
Dom transforms the following testcase:
static int a[199];
int
main ()
{
int i, x;
for (i = 0; i < 199; i++)
{
x = a[i];
if (x != i)
abort ();
}
return 0;
}
to
int
main ()
{
int i;
for (i = 0; i < 199; i = x + 1)
{
x = a[i];
if (x != i)
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-09-11 10:39 ---
// another testcase, compile with -O3
int b;
void foo1 (int);
void foo (void)
{
int i, j, k, l;
short v;
for (i = 0; i < 10; i ++)
{
for (l = 0; l < 10; l++)
{
--- Additional Comments From pcarlini at suse dot de 2005-09-11 09:52
---
Fixed for 4.1.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-11
09:48 ---
Subject: Bug 23781
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-11 09:48:41
Modified files:
libstdc++-v3 : ChangeLog
libstdc++-v3/inclu
// test case, compile with -O1 -ftree-loop-linear
int t [2][4];
void foo (void)
{
int i, j, k, v;
float e;
for (;;)
{
v = 0;
for (j = 0; j < 2; j ++)
{
for (k = 2; k < 4; k ++)
{
e = 0.0;
for (i = 0; i < 4; i ++)
// testcase, compile with -O1 -fno-tree-dominator-opts :
void foo (int p[100], int k, ...)
{
int j, *q;
__builtin_va_list ap;
__builtin_va_start (ap, k);
q = __builtin_va_arg (ap, int *);
for (j = 0; j < 100; j++)
p [j] = q [j];
__builtin_va_end(ap);
}
// compiler output:
capifunc
--- Additional Comments From appfault at hotmail dot com 2005-09-11 08:04
---
Invalid? So whenever behavior is undefined by the C standard, would it be ok
to delete the user's harddrive as well? This is ridiculous - fix the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10719
// test case, compile with -O3
int foo1 (void);
void foo2 (int);
static int foo9 (int k)
{
return ((k == 0x00) || (k == 0x10) || (k == 0x14));
}
static int foo8 (int *p)
{
return *p;
}
void foo6 (int *p)
{
int a, b, c, d, e = 0;
foo8 (p);
b = 0;
do
{
b++;
a = foo1();
88 matches
Mail list logo
