Dear Tobias,
On Fri, Dec 2, 2011 at 10:07 PM, Tobias Burnus wrote:
> This patches fixes my previous MOVE_ALLOC patch. The standard states for TO:
> "It shall be polymorphic if FROM is polymorphic."
>
> I somehow read this bijectively, but the it is actually allowed to have a
> nonpolymorphic FROM
Dear Tobias,
This is OK for both 4.6 and 4.7.
Many thanks, sir!
Paul
On Tue, Nov 29, 2011 at 7:32 PM, Tobias Burnus wrote:
> Dear all,
>
> gfortran 4.6 and 4.7 have a too tight check whether a variable can be
> modified if the actual argument is INTENT(IN). This patch relaxes/fixes the
> check
This implements a new C++ trait, __is_final, to query the 'final'
specifier that 4.7 supports. The trait is needed for the library so we
can detect when it's not possible to derive from a type in order to
exploit the empty base-class optimisation. This affects all
containers, std::shared_ptr, std:
On 3 December 2011 12:00, Jonathan Wakely wrote:
> This implements a new C++ trait, __is_final, to query the 'final'
> specifier that 4.7 supports. The trait is needed for the library so we
> can detect when it's not possible to derive from a type in order to
> exploit the empty base-class optimisa
On 23/11/2011 08:43, Eric Botcazou wrote:
> On 23/11/2011 07:28, Eric Botcazou wrote:
>>> /usr/local/src/trunk/objdir.withada/./gcc/xgcc
>>> -B/usr/local/src/trunk/objdir.withada/./gcc/
>>> -B/usr/i686-pc-cygwin/bin/ -B/usr/i686-pc-cygwin/lib/ -isystem
>>> /usr/i686-pc-cygwin/include -isystem /usr/
* doc/xml/manual/utilities.xml: Remove outdated text.
I think we can assume everyone has a compiler that supports member
function templates.
Committed to trunk.
Index: doc/xml/manual/utilities.xml
===
--- doc/xml/manual/utili
Are there any objections to this patch?
I find the function easier to parse in this form and it allows it to
be constexpr. Maybe more importantly, it determines the memory order
to be used by compare_exchange_xxx on failure so I think
__cmpexch_failure_order is a more descriptive name than
__calcu
On Fri, Dec 02, 2011 at 08:10:11PM +1030, Alan Modra wrote:
> On Thu, Dec 01, 2011 at 12:36:08PM +0100, Jakub Jelinek wrote:
> > On Thu, Dec 01, 2011 at 09:58:08PM +1030, Alan Modra wrote:
> > > The GOMP_task change fixes a similar potential problem. Bootstrapped
> > > and regression tested powerp
OK.
Jason
On Fri, Dec 2, 2011 at 6:39 PM, Michael Zolotukhin
wrote:
>>
>> Shouldn't we add a variant for each testcase so that we still
>> excercise both 128-bit and 256-bit vectorization paths?
>
> These tests are still good to test 128-bit vectorization, the changes
> was made just to make sure that 256-b
gfortran wrongly marks the selector of a SELECT TYPE as having the
pointer or allocatable attribute. Result: No error if one tries to
change the allocation status.
"If the selector is allocatable, it shall be allocated; the associate
name is associated with the data object and does not have th
On Fri, Dec 2, 2011 at 8:26 PM, Jakub Jelinek wrote:
> Hi!
>
> As I found during investigation of PR51387, e.g. on the attached testcase
> we generate pretty bad code (for f1 even with bigger N like 256 for avx2),
> because after vectorization cunroll unrolls the loops completely and we
> end up w
On Fri, Dec 2, 2011 at 8:28 PM, Jakub Jelinek wrote:
> On Fri, Dec 02, 2011 at 02:27:40PM +0100, Richard Guenther wrote:
>> This change seems wrong. We are turning valid gimple
>>
>> # DEBUG D#2 => transfer.0 [with addres taken]
>>
>> into invalid one
>>
>> # DEBUG D#2 => transfer.0 [without ad
FSF gcc currently doesn't handle -fno-pie and friends properly under Lion.
The darwin11 linker now defaults to -pie and must be explicitly passed -no_pie
in such cases. The following patch extends LINK_GCC_C_SEQUENCE_SPEC to handle
those instances which should pass -no_pie to the linker. The
gc
On 12 November 2011 15:14, Jonathan Wakely wrote:
> On 12 November 2011 15:04, Marc Glisse wrote:
>>
>> Debug-mode seems to check that first,last is a valid range, is a heap, but
>> not that it is not empty. Maybe it could?
>
> Good idea, thanks. I'll change that.
As promised.
* include/
patch ping ...
On 7 November 2011 09:58, Jonathan Wakely wrote:
>
> And then this adjusts and for C++11 conformance.
>
> C++11 requires stdbool.h so providing it is not a GCC extension, but
> defining _Bool is. I don't see the point of defining bool, true and
> false as macros in C++ and it's ex
Once you want to check it in, consider any Darwin aspects pre-approved.
fix typo in message, committed as obvious.
Matthias
2011-12-03 Matthias Klose
* expr.c (SPECIAL_WIDE): Fix typo in message.
Index: gcc/java/expr.c
===
--- gcc/java/expr.c (revision 181969)
+++ gcc/java/expr.c (
> I mean, that, when 256-bit vectorization is enabled we still use 128bit
> vectorization if the arrays are too short for 256bit vectorization. You'll
> lose this test coverage when you change the array sizes.
That's true, but do we need all these test both with short and long
arrays? We could hav
Dear Tobias,
Are you checking to see if the patches really are reviewed :-)
Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c (Revision 181967)
+++ gcc/fortran/class.c (Arbeitskopie)
@@ -188,7 +188,8 @@ gfc_build_class_symbol (g
Hi Richard,
On 2 Dec 2011, at 23:36, Iain Sandoe wrote:
On 2 Dec 2011, at 22:59, Richard Henderson wrote:
I personally think the whole thing would be much easier to read
without relying on the redzone. Aside from that, there's actually
very little real difference in the two files. Essent
Dear all,
Attached is a patch which fixes bug target/51393:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51393
Also attached, avx_bug.c is a minimal example to reproduce the bug
(requires an AVX-capable CPU):
$ gcc -O3 -mavx avx_bug.c
$ ./a.out 0x8000
in = 0x8000
out =
Hello,
Consider this short C++ example annotated with line numbers for better
legibility and compiled without optimization:
1 class MyClass
2 {
3 public:
4MyClass() {};
5 ~MyClass() {};
6 };
7
8 int
9 main ()
10 {
11
Dear Paul,
Paul Richard Thomas wrote:
Are you checking to see if the patches really are reviewed :-)
t
I am - but involuntarily. I am sure that I build and regtested - but
seemingly a different tree :-(
The latter change gets rejected with my class array patch in place
because I have:
I a
Another OOP-related patch: If one uses type extension, the first
REF_COMPONENT does not necessarily refer directly to a component in the
linked list starting at sym->ts.u.derived->components.
Using simply ref->u.c.component directly seems to work fine, thus, I do
this with this patch.
Build
Hello world,
the recent discussion has convinced me that there is no way to
mix OMP workshares and common function elimination as practiced by
frontend-passes.c. This patch therefore disables that
particular optimization within workshares.
Regression-tested. OK for trunk?
Thomas
2011
Hello Paolo,
Paolo Carlini a écrit:
> Index: cp/call.c
> ===
> --- cp/call.c (revision 181875)
> +++ cp/call.c (working copy)
> @@ -3373,7 +3373,7 @@ static struct z_candidate *
> build_user_type_conversion_1 (tree totype, tree exp
On Sat, Dec 03, 2011 at 09:58:17PM +0100, Thomas Koenig wrote:
> the recent discussion has convinced me that there is no way to
> mix OMP workshares and common function elimination as practiced by
> frontend-passes.c. This patch therefore disables that
> particular optimization within workshares.
Hello,
in macro.c, I have inadvertently added an "inline" function specifier
to the definition of the static tokens_buff_remove_last_token
definition while its previous prototype didn't have the "inline".
There is code using the that function before the definition (and after
its declaration) and
On 02/12/11 11:40, Richard Sandiford wrote:
> Tom de Vries writes:
>> On 27/11/11 23:59, Eric Botcazou wrote:
No, DELETED_LABEL notes still work just fine. It depends on how you
remove the label and replace it with a note, and Tom isn't showing
what he did, so...
>>>
>>> I agree tha
On 12/03/2011 04:25 PM, Dodji Seketeli wrote:
This might be a theoretical nit, but it looks like if expr is
error_mark_node, we'd crash as well, because of the line below that comes
right after the comment above:
gcc_assert (!MAYBE_CLASS_TYPE_P (fromtype) || !MAYBE_CLASS_TYPE_P (totype)
On Dec 2, 2011, at 10:48 AM, Georg-Johann Lay wrote:
> http://gcc.gnu.org/viewcvs?view=revision&revision=181933
>
> Committed the following, obvious fix to a test case that assumed
> sizeof(int) = 4:
Thanks.
On Nov 30, 2011, at 6:28 AM, Iain Sandoe wrote:
> While trying to track down the vector unwind problems on ppc-darwin, I made
> some tidy-ups for "save_world()".
> In the end, that was not where the main problem, lay - but I did find a few
> things wrong there on the way - they should be fixed, e
On Dec 3, 2011, at 7:25 AM, Jack Howarth wrote:
> FSF gcc currently doesn't handle -fno-pie and friends properly under Lion.
> The darwin11 linker now defaults to -pie
> Okay for gcc trunk and backports to gcc-4_5-branch/gcc-4_6-branch?
Ok.
Jason Merrill a écrit:
> On 12/03/2011 04:25 PM, Dodji Seketeli wrote:
>> This might be a theoretical nit, but it looks like if expr is
>> error_mark_node, we'd crash as well, because of the line below that comes
>> right after the comment above:
>>
>>gcc_assert (!MAYBE_CLASS_TYPE_P (fromtype
I've approved and applied this...
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog (revision 181983)
+++ testsuite/ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2011-12-03 Dominique d'Humieres
+
+ PR obj-c++/51349
+ *
On Nov 30, 2011, at 6:06 AM, Matthew Gretton-Dann wrote:
> The attached patch changes another use of random in the testsuite to rand.
> Please can someone review.
Ok? is the canonical spelling for this... :-)
Ok. (is the canonical answer.)
> 2011-11-30 Matthew Gretton-Dann
>
> * gc
37 matches
Mail list logo
