Sent from my iPhone
On Mar 13, 2009, at 9:11 PM, howarth at nitro dot med dot uc dot edu
gcc-bugzi...@gcc.gnu.org wrote:
There are a number of aliasing warnings coming out of tree-ssa-
structalias.c
when compiling code in pymol which uses their endianswap.h header at
-O3 -Wall.
The
--- Comment #4 from pinskia at gmail dot com 2009-03-14 06:03 ---
Subject: Re: New: strange aliasing warnings compiling pymol under gcc 4.4
Sent from my iPhone
On Mar 13, 2009, at 9:11 PM, howarth at nitro dot med dot uc dot edu
gcc-bugzi...@gcc.gnu.org wrote:
There are a
Sent from my iPhone
On Mar 13, 2009, at 8:54 PM, rob1weld at aol dot com gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #2 from rob1weld at aol dot com 2009-03-14 03:54
---
(In reply to comment #1)
Subject: Re: New: The Driver hides undefined reference messages
from
shared
--- Comment #3 from pinskia at gmail dot com 2009-03-14 06:14 ---
Subject: Re: The Driver hides undefined reference messages from shared libs
(but not object files) in linker phase
Sent from my iPhone
On Mar 13, 2009, at 8:54 PM, rob1weld at aol dot com
gcc-bugzi...@gcc.gnu.org
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-03-14
06:25 ---
Well, these two offending inlined routines do have the comments...
/* Only works with aligned 4-byte quantities, will cause a bus error */
/* on some platforms if used on unaligned data.
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-14 08:11 ---
Subject: Bug 39454
Author: jakub
Date: Sat Mar 14 08:10:55 2009
New Revision: 144857
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144857
Log:
PR bootstrap/39454
* cse.c (fold_rtx): Don't
--- Comment #4 from jakub at gcc dot gnu dot org 2009-03-14 08:12 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #22 from d dot frey at gmx dot de 2009-03-14 08:52 ---
(In reply to comment #21)
Now I think I know the conservative way we want to go for the branch: just
change shared_ptr::operator* to always use something with the same semantics
of std::tr1::add_reference. For
--- Comment #23 from d dot frey at gmx dot de 2009-03-14 08:53 ---
Created an attachment (id=17463)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17463action=view)
show inconsistency with is_abstract
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39405
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-03-14 09:32 ---
You can work around it in a gcc specific way by doing
typedef int my_aliased_int __attribute__((may_alias));
and using
my_aliased_int *data = (int *) v;
my_aliased_int *N;
This forces TBAA not to be applied
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-03-14 09:32 ---
Invalid.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pault at gcc dot gnu dot org 2009-03-14 09:58 ---
There is no reason at all why this cannot be fixed.
Adding non-standard on non-standard doesn't seem too bad:-)
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38273
--- Comment #4 from pault at gcc dot gnu dot org 2009-03-14 09:56 ---
Helps to confirm it:-)
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from paolo dot carlini at oracle dot com 2009-03-14 12:06
---
I agree with your analysis. Can you please open a separate PR about
__is_abstract (which would be a C++ report): currently, we are trying to
complete the types, but we do not error out in case of
--- Comment #16 from hjl dot tools at gmail dot com 2009-03-14 15:01
---
There is
pa/pa.h:#define SHIFT_COUNT_TRUNCATED 1
PR 39454 is a SHIFT_COUNT_TRUNCATED bug, which is fixed by revision 144857.
Does revision 144857 fix this bug?
--
--- Comment #2 from nightstrike at gmail dot com 2009-03-14 15:46 ---
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00638.html
--
nightstrike at gmail dot com changed:
What|Removed |Added
--- Comment #2 from nightstrike at gmail dot com 2009-03-14 15:49 ---
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00636.html
--
nightstrike at gmail dot com changed:
What|Removed |Added
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2009-03-14
15:51 ---
Subject: Re: [4.4 Regression] ICE at dwarf2out.c:10353 in
loc_descriptor_from_tree_1
There is
pa/pa.h:#define SHIFT_COUNT_TRUNCATED 1
PR 39454 is a SHIFT_COUNT_TRUNCATED bug, which is fixed by
--- Comment #3 from nightstrike at gmail dot com 2009-03-14 15:52 ---
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00634.html
--
nightstrike at gmail dot com changed:
What|Removed |Added
--- Comment #2 from nightstrike at gmail dot com 2009-03-14 15:54 ---
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00641.html
--
nightstrike at gmail dot com changed:
What|Removed |Added
--- Comment #5 from nightstrike at gmail dot com 2009-03-14 15:57 ---
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00640.html
--
nightstrike at gmail dot com changed:
What|Removed |Added
--- Comment #2 from nightstrike at gmail dot com 2009-03-14 16:00 ---
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00639.html
--
nightstrike at gmail dot com changed:
What|Removed |Added
--- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca 2009-03-14
16:15 ---
Subject: Re: [4.4 Regression] ICE at dwarf2out.c:10353 in
loc_descriptor_from_tree_1
The ICE doesn't occur if I replace parser.o.
I messed up in testing the above. The problem is actually in
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-03-14
16:24 ---
Thanks. One last question. Is the presence of the 'does break' warning from
tree-ssa-structalias.c considered to be more likely to indicate actual code
breakage than the 'will break' warning from
[forwarded from https://launchpad.net/bugs/342335
seen with 4.3 20090313, not seen on the trunk, not seen with -O1, or -O2
-fno-optimize-sibling-calls.
$ g++-4.3 -c -g -pthread -O2 -fvisibility=hidden -fvisibility-inlines-hidden
-Wall -W -fPIC qstring-minimal.ii
tools/qstring-minimal.cpp: In
--- Comment #1 from doko at ubuntu dot com 2009-03-14 16:54 ---
Created an attachment (id=17464)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17464action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39461
--
ayers at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|pinskia at gcc dot gnu dot |ayers at gcc dot gnu dot org
|org
--- Comment #9 from ayers at gcc dot gnu dot org 2009-03-14 17:05 ---
Fixed for 4.4.0
--
ayers at gcc dot gnu dot org changed:
What|Removed |Added
--
ayers at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ayers at gcc dot gnu dot org
|dot org
--- Comment #6 from ayers at gcc dot gnu dot org 2009-03-14 17:11 ---
Created an attachment (id=17465)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17465action=view)
patch for build_conditional_expr
This patch for build_conditional_expr is modeled after build_binary_op in that
it
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-03-14 17:15 ---
In 4.5 this warning indicates that the load/store will be simply eliminated.
For
4.4 a miscompilation is less likely.
Note that this warning is designed to have zero false positives (so either you
discovered a
I have a lot of cases where it would be possible (more or less trivial,
depending on the situation/code) to check if an assert() would fail at compile
time. In such cases, I would want that GCC gives a warning (or an error).
I understand that it's not possible to catch all cases but on such cases
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-14 17:20 ---
Is this a dup of PR39175?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
aesok at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aesok at gcc dot gnu dot org
|dot org
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-14 17:33 ---
You should be able to do this already with something like
void do_the_warning (void) __attribute__((warning(assertion always false)));
#define assert(X) \
if (__builtin_constant_p (X) \
!(X))
--- Comment #4 from vapier at gentoo dot org 2009-03-14 18:48 ---
i think this is a dupe of PR35964 ... and that bug indicates that this is a
regression from gcc-4.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36209
--- Comment #2 from ich at az2000 dot de 2009-03-14 19:48 ---
Really thanks a lot for that hint.
I did a small assert-implementation by my own:
http://openlierox.svn.sourceforge.net/viewvc/openlierox/include/cassert?view=markup
Btw., it seems that Apples GCC (even 4.2) does not
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-03-14 20:25 ---
The attribute is new in GCC 4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39462
The type a std::vector cannot work with classes with the protected
copy-constructors.
class A{
public:
explicit A(const A){};
};
std::vectorA v;
A a;
v.push_back(a); // an error
Copy protection deleting solves a question.
class B{
public:
B(const B){};
};
std::vectorB w;
B b;
w.push_back(b);
--- Comment #6 from rogerpack2005 at gmail dot com 2009-03-14 21:14 ---
anybody know if this bug is related to this post?
http://www.gamedev.net/community/forums/topic.asp?topic_id=482230
Thanks!
-=roger
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36834
--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2009-03-14
21:31 ---
Subject: Re: [4.4 Regression] ICE at dwarf2out.c:10353 in
loc_descriptor_from_tree_1
On Tue, 10 Mar 2009, jakub at gcc dot gnu dot org wrote:
You can start with trying if -O2 -fno-inline
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2009-03-14
22:50 ---
Interestingly the suggestion in Comment 6 introduces the new warning...
endianswap.h: In function 'swap4_aligned':
endianswap.h:113: warning: pointer targets in initialization differ in
signedness
--- Comment #1 from paolo dot carlini at oracle dot com 2009-03-14 23:36
---
According to the current C++ Standard, elements of std::vector must be
CopyConstructible (20.1.3) and such a type cannot have an explicit copy
constructor.
--
paolo dot carlini at oracle dot com changed:
--- Comment #4 from paolo dot carlini at oracle dot com 2009-03-14 23:41
---
Also - I admit not having studied in detail all your requirements, sorry about
that - I suppose you would be interested in static_assert, available with
-std=c++0x, in gcc4.3.x (and 4.4.x, of course):
--- Comment #5 from ich at az2000 dot de 2009-03-15 00:10 ---
(In reply to comment #4)
Also - I admit not having studied in detail all your requirements, sorry about
that - I suppose you would be interested in static_assert, available with
-std=c++0x, in gcc4.3.x (and 4.4.x, of
--- Comment #6 from paolo dot carlini at oracle dot com 2009-03-15 00:31
---
Hey, no problem really, just wanted to let you aware that the next Standard
will deliver an assert checked at compile time. In general, if you want
something special for the next releases of the C++ Standard,
--- Comment #25 from paolo at gcc dot gnu dot org 2009-03-15 00:44 ---
Subject: Bug 39405
Author: paolo
Date: Sun Mar 15 00:43:46 2009
New Revision: 144867
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144867
Log:
2009-03-14 Paolo Carlini paolo.carl...@oracle.com
PR
--- Comment #7 from ich at az2000 dot de 2009-03-15 00:58 ---
Hm yea, I thought already about that. But I cannot think of a good (and easy)
definition when an assert() should be checked at compile time and whether not.
And thus, I am not sure if that is something which belongs into the
--- Comment #26 from paolo dot carlini at oracle dot com 2009-03-15 00:54
---
This specific issue is fixed in 4_3-branch.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #9 from jason at gcc dot gnu dot org 2009-03-15 01:45 ---
I was planning to wait until 4.4 branches. If you'd rather have it in 4.4, I
can commit it now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39310
--- Comment #10 from paolo dot carlini at oracle dot com 2009-03-15 02:07
---
(In reply to comment #9)
I was planning to wait until 4.4 branches. If you'd rather have it in 4.4, I
can commit it now.
Well, if you ask me, yes, I would like to see it in 4.4. Thanks in advance.
--
--- Comment #20 from dave at hiauly1 dot hia dot nrc dot ca 2009-03-15
02:22 ---
Subject: Re: [4.4 Regression] ICE at dwarf2out.c:10353 in
loc_descriptor_from_tree_1
--- Comment #16 from hjl dot tools at gmail dot com 2009-03-14 15:01
---
There is
pa/pa.h:#define
--- Comment #8 from vapier at gentoo dot org 2009-03-15 05:27 ---
this has been fixed for gcc-4.4 ... time to close the bug ?
http://gcc.gnu.org/viewcvs?view=revrevision=136783
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33200
53 matches
Mail list logo
