--- 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=rev&revision=136783
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33200
--- 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 #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 #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 #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 C
--- 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 #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=gcc&view=rev&rev=144867
Log:
2009-03-14 Paolo Carlini
PR libstdc++/39405
--- 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, I
--- 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 cou
--- 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):
http:/
--- 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 #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
endians
--- 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 -fno-i
--- 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
The type a std::vector cannot work with classes with the protected
copy-constructors.
class A{
public:
explicit A(const A&){};
};
std::vector v;
A a;
v.push_back(a); // an error
Copy protection deleting solves a question.
class B{
public:
B(const B&){};
};
std::vector w;
B b;
w.push_back(b); /
--- 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
--- 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 support
--- 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 #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))
--
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 #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
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 #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 wron
--- 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=17465&action=view)
patch for build_conditional_expr
This patch for build_conditional_expr is modeled after build_binary_op in that
i
--
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 #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
Status|ASSI
--
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 #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=17464&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39461
[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 func
--- 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 c-common.c
--- 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 libcpp/ex
--- 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 #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 15:54 ---
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00641.html
--
nightstrike at gmail dot com changed:
What|Removed |Added
-
--- 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 #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 #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 #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 #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?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- 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 incompletenes
--- 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
Stat
--- 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
Status|UNCONFI
--- 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 t
--- 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=17463&action=view)
show inconsistency with is_abstract
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39405
--- 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 mai
--- 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 #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=gcc&view=rev&rev=144857
Log:
PR bootstrap/39454
* cse.c (fold_rtx): Don't modi
48 matches
Mail list logo
