[EMAIL PROTECTED]:~/bug$ g++ -v -save-temps test.cpp
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir
there are a bug when you mix structure and function. Only the first part of the
structure seems to act correctly. The best thing is to try this sample:
The tab and the pts must be equal in their components and it's not the case.
I saw another things I don't like (even if I think that the norm req
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 19:03
---
Fixed in 3.4.0 and above.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From gmorin1 at bloomberg dot net 2004-10-15 19:07 ---
Hi,
As far as I know, OpenPKG does not apply any patched on this gcc. Furthermore, I
have another gcc 3.4.2 built from the vanilla source on Solaris :
[EMAIL PROTECTED]:~$ /unix-SunOS-sparc-5.8-def/bin/g++ -o
irun/bin/gfortran -static test2.f90
test2.f90: In function 'MAIN__':
test2.f90:6: internal compiler error: in gfc_conv_string_parameter, at
fortran/trans-expr.c:1986
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
for t
--- Additional Comments From bangerth at dealii dot org 2004-10-15 19:17 ---
My fault: I missed the last line of the testcase where the instantiation
is. With this line I can reproduce this bug with both stock 3.4.2 as well
as with the present top-of-branch 3.4 compiler.
The bug does
--- Additional Comments From bangerth at dealii dot org 2004-10-15 19:17 ---
Confirmed indeed. Sorry for my initial oversight...
W.
--
What|Removed |Added
Statu
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 19:43
---
And mine too.
: Search converges between 2003-07-05-trunk (#285) and 2003-07-06-trunk (#286).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18020
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 19:44
---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-15 19:58
---
I can confirm that this patch fixes this bug and causes no testsuite
regressions. :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17406
--- Additional Comments From dr dot johan at gmail dot com 2004-10-15 19:59
---
I second this opinion! I tried the fix suggested below and my code now builds
with gfortran "gcc version 4.0.0 20041015 (experimental)".
/Johan
(In reply to comment #6)
> My
I'm running on a 32-bit AIX 5.1 box. GCC 3.3.5 was configured as follows and
bootstrapped.
# This directory was configured as follows:
/home/downloads/gcc/gcc-3.3.5/configure --with-gcc-version-trigger=/home/downloa
ds/gcc/gcc-3.3.5/gcc/version.c --host=powerpc-ibm-aix5.1.0.0 --enable-threads=po
--- Additional Comments From dje at gcc dot gnu dot org 2004-10-15 20:16 ---
Proposed patch:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01299.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18002
--- Additional Comments From tobi at gcc dot gnu dot org 2004-10-15 20:17 ---
I'm wondering how the call to gfc_typenode_for_spec (&c->ts) changes
c->backend_decl, but since this works you can send the patch (after adding
spaces before '(') to [EMAIL PROTECTED], and the person who origina
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 20:24
---
Yes 3.3.5 did not contained the patches, could you try 3.4.0 then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18024
--- Additional Comments From ejb at ql dot org 2004-10-15 20:34 ---
I think you misunderstood. I'm not suggesting -Wunitialized should turn on
-Winit-self; I'm suggesting the other way around. Since -Winit-self doesn't
work without -Wunitialized, it's pointless to have it without -Wunit
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 20:36
---
Mailed seemed to have bounced...
--
Allen Skees
[EMAIL PROTECTED]
-Original Message-
From: Allen Skees [mailto:[EMAIL PROTECTED]
Sent: Friday, October 15, 2004 4:31 PM
To: '[EMAIL PROTECTED]'
Sub
--- Additional Comments From ejb at ql dot org 2004-10-15 20:40 ---
In other words, instead of saying:
Note this option can only be used with the`-Wuninitialized' option, which in
turn only works with `-O1' and above.
say
Note this option automatically implies -Wunitialized, which only
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 20:46
---
Ok, now I understand (I was really busy this morning not to understand).
Confirmed, I will try to get this done for 4.1.0.
--
What|Removed |Added
Hi,
the following code compiles and runs, but gives output that is
incompatible with other tested F95 compilers:
program gfcbug18
real :: x = 1.23
! Minimum width formatting:
! gfortran prints "# 1.23#", i.e., a leading blank where other compilers won't
write(*, "('#',F0.2,'#')") x
end pr
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-15 21:11
---
Subject: Bug 14667
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-10-15 21:11:50
Modified files:
gcc/cp : ChangeLog decl.c parser.c
gc
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-15 21:11
---
Subject: Bug 17042
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-10-15 21:11:50
Modified files:
gcc/cp : ChangeLog decl.c parser.c
gc
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-15 21:11
---
Subject: Bug 17852
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-10-15 21:11:50
Modified files:
gcc/cp : ChangeLog decl.c parser.c
gc
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-10-15 21:15
---
Fixed in GCC 4.0.
--
What|Removed |Added
Status|ASSIGNED|RE
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-10-15 21:15
---
Fixed in GCC 4.0.
--
What|Removed |Added
Status|ASSIGNED|RE
--
Bug 16716 depends on bug 14667, which changed state.
Bug 14667 Summary: [4.0 Regression] ICE in
cp_parser_parse_and_diagnose_invalid_type_name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14667
What|Old Value |New Value
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-15 21:18
---
Subject: Bug 17042
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-10-15 21:18:08
Modified files:
gcc/cp : ChangeLog
gcc/testsuite : C
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-15 21:18
---
Subject: Bug 17852
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-10-15 21:18:08
Modified files:
gcc/cp : ChangeLog
gcc/testsuite : C
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-15 21:18
---
Subject: Bug 14667
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-10-15 21:18:08
Modified files:
gcc/cp : ChangeLog
gcc/testsuite : C
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-10-15 21:18
---
Fixed in GCC 4.0.
--
What|Removed |Added
Status|ASSIGNED|RE
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-15 21:18 ---
This is a regression from 3.3.3, which does not generate two consecutive andl.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18008
--- Additional Comments From jsm28 at gcc dot gnu dot org 2004-10-15 21:25 ---
Now we don't get any diagnostic for the testcase at all. From the
regression hunter I think my patch for bug 13801 is probably to blame for
that. In formal terms a diagnostic isn't required here, but I'm incl
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org |
Status|NEW
Hi,
the following code does not compile with gfortran, although it does
with g77:
PROGRAM GFCBUG19
DOUBLE PRECISION inf, nan
c IEEE exceptional values on Intel x87
DATA inf / Z'7FF0' /
DATA nan / Z'FFF8' /
print *, inf, nan
END
% g77 gf
The ia64-hpux version of GCC supports several options that don't appear
to be documented. I see at least the following:
-milp32
-mlp64
-mt
--
Summary: undocumented ia64-hpux options
Product: gcc
Version: 3.4.1
Status: UNCONFIRMED
Severit
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 21:49
---
: Search converges between 2004-08-26-trunk (#525) and 2004-08-27-trunk (#526).
Looking at the above date which is from using Phil's regression hunter, we can say
almost definitely
JSM's patch to fix bug
The included program does not appear to compile correctly
under gcc 3.4.2.
The following statement, which does not appear to work, begins on
line 123 --
seq t /* sequence of size 1 */
(
seq/* sequence of size 2
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 21:54
---
Confirmed.
--
What|Removed |Added
OtherBugsDependingO||5362
--- Additional Comments From jsm at polyomino dot org dot uk 2004-10-15 21:55
---
Subject: Re: [4.0 Regression] wrong error in presence of builtin
fn + K&R declaration.
On Fri, 15 Oct 2004, pinskia at gcc dot gnu dot org wrote:
> Looking at the above date which is from using Phil's r
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 21:55
---
Note IA64 also has some problems with undocumented target options see PR 5362.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5362
--- Additional Comments From skunk at iskunk dot org 2004-10-15 22:25 ---
Created an attachment (id=7360)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7360&action=view)
/usr/include/net/if.h from Tru64
As I am not familiar with the inclhack.def syntax, I am attaching an unmodified
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 22:49
---
Invalid as seq(seq (t)) is considered to call the copy constructor which is defined
___not___ to match
templates (by the standard). The 3.3 and before bug (is a different bug and is a dup
of one of the m
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 23:12
---
Never mind you are right Alan, I do need to use cc1plus but why. The RTL is wrong
already at .01.rtl.
So this is 3.4 regression (it might be a 3.3 regression also I don't know). But this
was fixed on the
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 23:15
---
Confirmed.
--
What|Removed |Added
Severity|normal |enhancemen
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 23:22
---
Confirmed.
--
What|Removed |Added
Severity|minor |enhancemen
--- Additional Comments From giovannibajo at libero dot it 2004-10-15 23:43
---
Created an attachment (id=7361)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7361&action=view)
Tentative patch
Can you try if this patch fixes it? Otherwise, you could try tweaking it a
little bit, if
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |giovannibajo at libero dot
|dot org |it
Status|UNCONFIRMED
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-10-16 00:08
---
It was an accident that error18.C was committed on the branch. I've now removed it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16002
--- Additional Comments From rth at gcc dot gnu dot org 2004-10-16 00:08 ---
I can't reproduce this today. Can anyone else?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17451
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-16 00:35
---
Something isn't right with the patch. The ChangeLog mentions a function
fix_with_system() that does not appear to exist. The build fails because
z_applyfix_prog's initializer doesn't match its type, and fi
--
What|Removed |Added
GCC host triplet||powerpc-ibm-aix5.1.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18024
--- Additional Comments From bernie at develer dot com 2004-10-16 00:44 ---
I can still see it with a recent snapshot from RawHide:
gcc version 3.4.2 20041006 (Red Hat 3.4.2-5)
So unless it has been accidentally fixed during the last
10 days, the bug is still in 3.4-branch.
--
htt
--- Additional Comments From belyshev at lubercy dot com 2004-10-16 00:50 ---
Still ICEs on today's 3.4 branch. (Note comment #8).
--
What|Removed |Added
Last reconfirmed|2
--- Additional Comments From giovannibajo at libero dot it 2004-10-16 02:00
---
Patch submitted:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01320.html
--
What|Removed |Added
---
--- Additional Comments From giovannibajo at libero dot it 2004-10-16 02:01
---
Patch submitted:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01319.html
--
What|Removed |Added
---
--
What|Removed |Added
Severity|normal |critical
Known to fail||3.4.0
Known to work|
Consider:
struct B {
unsigned bit : 1;
};
void
plus (struct B *b)
{
b->bit = b->bit + 1;
}
void
xor (struct B *b)
{
b->bit = b->bit ^ 1;
}
./cc1 -O2 -fomit-frame-pointer -mregparm=3 generates
plus:
xorb$1, (%eax)
ret
xor:
movb(%eax), %cl
andl$
--
What|Removed |Added
Summary|a twiddleing of a |an xor of a single bit
||bitfield is inefficient
http://gcc.gnu
Consider:
struct B {
unsigned bit : 2;
};
void
plus (struct B *b)
{
b->bit |= 1;
}
./cc1 -O2 -fomit-frame-pointer -mregparm=3 generates
plus:
movb(%eax), %cl
andl$3, %ecx
orl $1, %ecx
andl$3, %ecx
movl(%eax), %edx
andl$
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-16 03:05
---
Confirmed on PPC also. (note for PPC to get about the same code we have to use the
following
definition for the struct:
struct B {
unsigned unused: 31;
unsigned bit : 1;
};
).
--
What
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-16 03:09
---
No this is an Ada front-end problem.
I think the main issue is that the tree-ssa expects that INTEGER types are close to
the same and that
pointers to them are compatible if the types are them selves compa
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-16 03:11
---
For PPC:
struct B {
unsigned :30;
unsigned bit : 2;
};
Confirmed.
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2004-10-16 03:30
---
CC'ing also Bruce because he's the fixincludes maintainer. Bruce, BTW, as a
developer which digs for the first time in fixincludes, let me say that
fixincludes/README is not very clear about how 'make check
--- Additional Comments From mark at codesourcery dot com 2004-10-16 03:37 ---
Subject: Re: __alignof__ vs. typedefs
giovannibajo at libero dot it wrote:
>--- Additional Comments From giovannibajo at libero dot it 2004-10-16 02:00
>---
>Patch submitted:
>http://gcc.gnu.org/ml
--- Additional Comments From mark at codesourcery dot com 2004-10-16 03:38 ---
Subject: Re: __alignof__(double) not compile time constant
inside template class
giovannibajo at libero dot it wrote:
>--- Additional Comments From giovannibajo at libero dot it 2004-10-16 02:01
>
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-16 03:46 ---
All the interesting events happen in store_field.
When store_field expands "() (unsigned char) v",
it generates an AND with 3 because () is an anonymous type
of two-bit integer.
When it expands the assignment
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-16 03:50 ---
>From IRC:
kazu: Looks like PR 18008 only has a single AND with -march=pentiumpro,
but two ANDs with -march=i386
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18008
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-16 04:05
---
Actually there are two ands for -march=pentiumpro also:
movl4(%esp), %ecx
movzbl 8(%esp), %edx <--- one
movl(%ecx), %eax
andl$3, %edx <--- two
andl$
struct B {
unsigned bit : 1;
};
void
ior (struct B *b)
{
b->bit |= 1;
}
I get:
ior (b)
{
:
b->bit = () (unsigned char) ((signed char) b->bit | 1);
return;
}
Note that we could just say b->bit = 1;
--
Summary: OR of a bitfield and a constant is not optimized at tree
101 - 169 of 169 matches
Mail list logo
