the act of #including iostream or any of the streams and using the
-fpack-struct switch causes the compiler to flag lots of errors that it
normally wouldn't without the switch. adding -O3 makes the problem worse.
this is a consistent problem.
This problem persists in 5.1.4 version of MinGW (gcc
--- Comment #1 from jmichae3 at yahoo dot com 2009-03-09 06:32 ---
Created an attachment (id=17420)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17420action=view)
-fpack-struct -O3 with iostream .ii file
g++ -v -save-temps -fpack-struct -O3 io.cpp
this is the generated io.ii
--- Comment #1 from rob1weld at aol dot com 2009-03-09 06:36 ---
Also in contrib/test_summary :
# (C) 1998, 1999, 2000, 2002 Free Software Foundation
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39138
--- Comment #1 from rob1weld at aol dot com 2009-03-09 06:40 ---
Fix:
/* munmap ((void *)computed_offset, computed_len); */
munmap ((caddr_t)computed_offset, computed_len);
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39279
--- Comment #2 from jmichae3 at yahoo dot com 2009-03-09 06:41 ---
Created an attachment (id=17421)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17421action=view)
-fpack-struct with iostream .ii file
g++ -v -save-temps -fpack-struct io.cpp
both attachments ( .ii files) are from
--- Comment #3 from jmichae3 at yahoo dot com 2009-03-09 06:45 ---
Created an attachment (id=17422)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17422action=view)
io.cpp, an offending source file
problem is it #includes iostream if -fpack-struct is used. that is all that
is
--- Comment #4 from jmichae3 at yahoo dot com 2009-03-09 06:50 ---
Created an attachment (id=17423)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17423action=view)
source that #includes istream and fails just as miserably with -fpack-struct
C:\prj\test\iostreamdosg++ -v
--- Comment #5 from jmichae3 at yahoo dot com 2009-03-09 06:55 ---
Created an attachment (id=17424)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17424action=view)
source that #includes fstream which also fails miserably with -fpack-struct
new attachment: source for f.cpp
--- Comment #6 from jmichae3 at yahoo dot com 2009-03-09 06:57 ---
Created an attachment (id=17425)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17425action=view)
f.ii for fstream problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39404
--- Comment #7 from jmichae3 at yahoo dot com 2009-03-09 06:59 ---
Created an attachment (id=17426)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17426action=view)
i.ii for istream problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39404
--- Comment #13 from dannysmith at users dot sourceforge dot net
2009-03-09 07:46 ---
(In reply to comment #12)
Was this broken in 4.3 compilers? Is it a 4.4 regression?
This is not a new bug in the compiler (the same multiple definition will occur
with 3.4.5) , but an old
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-03-09
07:52 ---
From gcc.info:
*Warning:* the `-fpack-struct' switch causes GCC to generate code
that is not binary compatible with code generated without that
switch. Additionally, it makes the code
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-09 08:22 ---
This isn't related to just bool, e.g.:
void
foo (unsigned char b)
{
switch ((unsigned int) b)
{
case 1:
case 257:
break;
}
}
also results in
pr39371-2.C:7: warning: large integer implicitly
--- Comment #2 from cneil at yahoo dot com 2009-03-09 09:58 ---
I think I'm hitting the same bug as the reporter.
i686-pc-linux-gnu-gcc argp-help.c -c -std=gnu99 -fgnu89-inline -O2 -Wall
-Winline -Wwrite-strings -fmerge-all-constants -fno-strict-aliasing -ggdb
-march=i686 -pipe
--- Comment #3 from cneil at yahoo dot com 2009-03-09 10:00 ---
Created an attachment (id=17427)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17427action=view)
preprocessed argp-help.c
If any additional information is needed, I'll do my best to provide it.
--
--- Comment #4 from cneil at yahoo dot com 2009-03-09 10:14 ---
OK, maybe I should slept before I submitted this.
1. The glibc-2.9 snapshot is from 20081201. I am not capable of time travel.
2. I successfully compiled this same glibc-2.9 snapshot with the gcc-4.4
snapshot from
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-09 10:31 ---
Patch posted: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00463.html
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Can't see why this shouldn't work with std::shared_ptr; changing the type of
m_foo to std::shared_ptrfoo, i.e. leaving out the redundant template
argument, changes nothing; only when making foo a class instead of a class
template, and removing all template arguments, does it compile.
--- Comment #5 from falk at debian dot org 2009-03-09 10:59 ---
Here's a test case:
void *p;
extern inline void *f1(int n) {
asm volatile( : =m(*(struct { char x[n]; }*) p));
}
int x;
extern inline void f2() {
x ? f1(1) : f1(2);
}
inline void f3() { f2(); }
void f4() { f3();
--- Comment #6 from jakub at gcc dot gnu dot org 2009-03-09 11:09 ---
Confirmed. Simplified testcase:
extern inline void *
asmfn (void *dest, const void *src, unsigned long n)
{
asm volatile (
: =m (*(struct { char x[n]; } *) dest)
: r (n), r (dest), r (src),
m (*(struct { char
--- Comment #7 from jakub at gcc dot gnu dot org 2009-03-09 11:28 ---
Oops, sorry. I guess the problem is that this VL type isn't gimplified.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from davidgkinniburgh at yahoo dot co dot uk 2009-03-09
11:33 ---
Thanks Jerry.
PS
CHARACTER(80) :: str
no longer needed in test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39402
--- Comment #8 from davidgkinniburgh at yahoo dot co dot uk 2009-03-09
11:34 ---
Thanks Jerry.
PS
CHARACTER(80) :: str
no longer required in test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39402
I just tried to compile the Suse Linux package sparse sparse-0.4.1.git1-1.56
with the GNU C compiler version 4.4 snapshot 20090306
and the compiler said
sparse.c: In function 'check_context':
sparse.c:546: internal compiler error: in referenced_var_lookup, at
tree-dfa.c:563
Please submit a full
--- Comment #8 from jakub at gcc dot gnu dot org 2009-03-09 11:52 ---
Created an attachment (id=17428)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17428action=view)
gcc44-pr39394.patch
Patch I'm going to bootstrap/regtest.
--
jakub at gcc dot gnu dot org changed:
--- Comment #1 from dcb314 at hotmail dot com 2009-03-09 11:53 ---
Created an attachment (id=17429)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17429action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39406
It was just brought to my attention that this fails to compile:
template typename void c();
#include stack
In file included from
/sbcimp/run/pd/gcc/32-bit/4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../include/c++/4.3.2/stack:67,
from mark.cc:2:
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-09 13:16 ---
This is likely dup of PR39360, please retry with a newer snapshot.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from matz at gcc dot gnu dot org 2009-03-09 13:25 ---
It's also PRE that produces such patterns, so moving predcom behind
vectorization alone won't help this problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39300
--- Comment #1 from paolo dot carlini at oracle dot com 2009-03-09 14:00
---
disgusting ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
--- Comment #9 from jakub at gcc dot gnu dot org 2009-03-09 14:01 ---
Subject: Bug 39394
Author: jakub
Date: Mon Mar 9 14:01:29 2009
New Revision: 144727
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144727
Log:
PR tree-optimization/39394
* gimplify.c
--- Comment #2 from paolo dot carlini at oracle dot com 2009-03-09 14:02
---
FWIW, if I use v3 together with the Intel C++ compiler, it builds...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
--- Comment #10 from jakub at gcc dot gnu dot org 2009-03-09 14:03 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-03-09 14:25
---
(In reply to comment #2)
FWIW, if I use v3 together with the Intel C++ compiler, it builds...
That's interesting, Comeau's online compiler gives a very similar error to gcc
4.3.2
--
$ uname -a
system type: AIX aix52a 1 6 000921F2D700
$ gcc -v
Using built-in specs.
Target: powerpc-ibm-aix6.1.0.0
Configured with: ../configure --with-as=/usr/bin/as --with-ld=/usr/bin/ld
--enable-languages=c,c++,java --prefix=/opt/freeware --enable-threads
--enable-version-specific-runtime-libs
--- Comment #1 from amit at mobiletornado dot com 2009-03-09 14:38 ---
Created an attachment (id=17430)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17430action=view)
the preprocessed file (gzipped)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39409
--- Comment #5 from r dot emrich at de dot tecosim dot com 2009-03-09
15:07 ---
(In reply to comment #4)
Sorry, pex_run co aren't the reason for this issue. By further debugging I
found that for bigger functions using alloca with variable sizes wrong code is
generated for
--- Comment #4 from paolo dot carlini at oracle dot com 2009-03-09 15:08
---
Before considering touching the library, I want evidence that at least another
widespread implementation has that operator somehow different than the obvious
way. Besides, the issue affects queue too, of
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-09 15:36 ---
You need to specify that the registers are clobbered by the asm. The only
way to do that is to use output constraints (+D, +c, etc.) on proper
temporaries.
int lent = len;
char *dstt = dst;
char *srct = src;
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-03-09 15:37 ---
This flag isn't supposed to be used with libstdc++.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-03-09 15:40 ---
I think this is more likely a C++ frontend issue. At least I cannot believe
this behavior is mandated by the std ;)
Jason?
--
rguenth at gcc dot gnu dot org changed:
What|Removed
Sent from my iPhone
On Mar 9, 2009, at 8:36 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-09
15:36 ---
You need to specify that the registers are clobbered by the asm.
The only
way to do that
--- Comment #2 from pinskia at gmail dot com 2009-03-09 15:57 ---
Subject: Re: Excessive optimization issue
Sent from my iPhone
On Mar 9, 2009, at 8:36 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #1 from rguenth at gcc dot gnu dot org
--- Comment #8 from hjl dot tools at gmail dot com 2009-03-09 15:58 ---
Icc 11 has no problems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
Sent from my iPhone
On Mar 9, 2009, at 8:40 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-03-09
15:40 ---
I think this is more likely a C++ frontend issue. At least I cannot
believe
this behavior
--- Comment #9 from pinskia at gmail dot com 2009-03-09 15:59 ---
Subject: Re: Parse error in stack when user declares template-name c
Sent from my iPhone
On Mar 9, 2009, at 8:40 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #7 from
Hi Team,
I have 'GNAT BUG DETECTED' error message when I try to compile my project. I am
providing the more simple example of source code which will help to reproduce
the problem.
Please, advise
+===GNAT BUG DETECTED==+
| 4.3.2
--- Comment #10 from jwakely dot gcc at gmail dot com 2009-03-09 16:08
---
reduced:
template typename struct x;
template typename struct y { int x; };
templatetypename T
bool operator(const yT l, const yT r) { return l.x r.x; }
It doesn't happen except in a template context, so it
--- Comment #11 from paolo dot carlini at oracle dot com 2009-03-09 16:19
---
Better... ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
--- Comment #12 from paolo dot carlini at oracle dot com 2009-03-09 16:24
---
Seriously, thanks Jonathan for the reduced C++ snippet. Really, this way of
seeing the issue makes much more sense to me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
struct S { int i; };
void
bar (const void *x, unsigned long y)
{
const union { struct S a[y / sizeof (struct S)]; } *u = x;
}
void
foo (const void *x, unsigned long y)
{
bar (x, y);
}
ICEs at -O[23s] -g with
internal compiler error: in gen_tagged_type_instantiation_die, at
dwarf2out.c:14850
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39412
dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC host triplet: GCC-4.4.0 (20090309), Cygwin, Windows XP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39413
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-03-09 17:42
---
This is related to PR 11814 or is the same bug. I thought there was an exact
duplicate of this parsing issue but I cannot find it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to
--- Comment #1 from paolo dot carlini at oracle dot com 2009-03-09 17:48
---
let's try to simplify the issue as much as possible... are defaulted / deleted
functions really necessary to trigger the bug? Thus, is c++0x mode really
necessary?
--
--- Comment #2 from paolo dot carlini at oracle dot com 2009-03-09 18:10
---
The below, not using any header neither C++0x mode (very likely can be further
reduced), doesn't compile with mainline and 4_3-branch, does with EDG-based
compilers in strict mode:
templatebool
class
--- Comment #14 from jwakely dot gcc at gmail dot com 2009-03-09 18:13
---
aha, on PR 11814 you mention PR 20308 which is the same.
Thanks, Andrew!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
--- Comment #15 from pinskia at gcc dot gnu dot org 2009-03-09 18:16
---
*** This bug has been marked as a duplicate of 10200 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from pinskia at gcc dot gnu dot org 2009-03-09 18:16
---
*** Bug 39407 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2009-03-09 18:17
---
Volunteers for a better Summary?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39413
The following code is invalid, but currently accepted by gfortran:
procedure(iabs) :: p
integer :: p
end
It is also accepted when the two statements are reversed in order.
It's not completely obvious to me whether this variant is invalid, too:
procedure() :: p
integer :: p
It is rejected by
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39413
--- Comment #4 from jakub at gcc dot gnu dot org 2009-03-09 19:34 ---
Subject: Bug 39371
Author: jakub
Date: Mon Mar 9 19:34:10 2009
New Revision: 144732
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144732
Log:
PR c++/39371
* semantics.c (finish_switch_cond):
--- Comment #5 from jakub at gcc dot gnu dot org 2009-03-09 19:35 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known
This is silently accepted:
struct T { };
struct T_impl: public T { };
T_impl *g(T *tp) { return static_castconst T_impl*(tp); }
The result type of the static_cast is pointer-to-const and should not
convert to a pointer-to-non-const. This seems to be specific to when
it is used as a
--- Comment #10 from jmichae3 at yahoo dot com 2009-03-09 20:12 ---
I didn't read that in the documentation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39404
#include iostream
#include map
#include string
// Demonstrate unexpected behaviour of std::map::operator[] when used in a read
// context, e.g. on the right hand side of an assignment.
//
// The intended application is a shell environment table, where accessing a
// non-existent variable should
--- Comment #1 from hjl dot tools at gmail dot com 2009-03-09 20:52 ---
This is introduced by revision 117493:
http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00158.html
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00239.html
--
hjl dot tools at gmail dot com changed:
What
--- Comment #1 from paolo dot carlini at oracle dot com 2009-03-09 20:53
---
There is nothing wrong here, the bahavior is fully specified in the Standard,
23.3.1.2 as:
Returns: (*((insert(make_pair(x, T(.first)).second.
Note, our inline documentation comments are also very clear
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-09 21:12 ---
Yeah, before r128631 (PR debug/33316) it ICEd in modified_type_die, after it in
gen_tagged_type_instantiation_die.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39412
--- Comment #2 from glyn at adgie dot f9 dot co dot uk 2009-03-09 21:25
---
Thanks Paolo, I suspected that this was not a bug in libstdc++, but
standard-compliant behaviour.
It just seems so unexpected, when compared to other languages that have maps,
e.g. tables in Lua. It is also
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-03-09 21:28 ---
It is hard for the library to know if we are doing an insert or doing an
extract as there is only one type of operator[] really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39416
--- Comment #1 from burnus at gcc dot gnu dot org 2009-03-09 22:00 ---
procedure() :: p
integer :: p
I think it is valid; ifort 11beta also accepts it. (NAG 5.1 doesn't.)
Looking at 12.3.2.3 Procedure declaration statement one sees that
PROCEDURE() is has the same effect as the
Attached is a small program that computes some values and puts them in a
std::vector. The values are stored in the `init' variable, but when
optimizations are enabled, the data actually added to the vector is garbage.
I've done a little testing and the problem exists when compiling with -O and
--- Comment #1 from maksverver at geocities dot com 2009-03-09 23:19
---
Created an attachment (id=17431)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17431action=view)
The test case that fails
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39417
--- Comment #2 from maksverver at geocities dot com 2009-03-09 23:21
---
Created an attachment (id=17432)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17432action=view)
The working tree code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39417
--- Comment #3 from maksverver at geocities dot com 2009-03-09 23:21
---
Created an attachment (id=17433)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17433action=view)
The broken tree code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39417
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-03-09 23:22 ---
This works on the trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39417
--- Comment #3 from casmyu at gmail dot com 2009-03-10 01:23 ---
Hi:
I have changed the code as you said, but it is more error now.
1 #include stdio.h
2
3 int main()
4 {
5 char src[30] = {This is a test message.\n};
6 char dst[30];
7 int len = 25;
8
9
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2009-03-10
01:47 ---
Subject: Re: [4.4 Regression] ICE at dwarf2out.c:10353 in
loc_descriptor_from_tree_1
--- Comment #11 from hjl dot tools at gmail dot com 2009-03-08 17:40
---
It seems that stage2 cc1plus is
--- Comment #3 from contact at multimedia dot cx 2009-03-10 03:01 ---
Confirmed fixed with revision 144720. Thanks.
--
contact at multimedia dot cx changed:
What|Removed |Added
--- Comment #13 from hjl dot tools at gmail dot com 2009-03-10 03:52
---
(In reply to comment #12)
Subject: Re: [4.4 Regression] ICE at dwarf2out.c:10353 in
loc_descriptor_from_tree_1
--- Comment #11 from hjl dot tools at gmail dot com 2009-03-08 17:40
---
It
--- Comment #4 from rob1weld at aol dot com 2009-03-10 04:22 ---
(In reply to comment #3)
Dismal Testsuite results are here:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02284.html
Rob
Great results are here:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02375.html
--
--- Comment #4 from rob1weld at aol dot com 2009-03-10 04:27 ---
(In reply to comment #3)
(In reply to comment #1)
MIRO: Mudflap Improved with Referent Objects - Works on OpenSolaris also.
http://gcc.gnu.org/wiki/MIRO
Results for gcc version 4.4.0 20080520 (experimental) [miro
85 matches
Mail list logo
