Dear Tobias,
>
> OK for the trunk?
>
OK.
>>
>> PS: There are still issues with polymophic coarrays; in particular,
>> argument passing [cf. coarray/poly_run_1.f90] and SELECT TYPE still fail in
>> various ways.
>
It is remarkable just how many ways [OOP] in any shape or form can
fail! Adding c
DR 1313 removes the blanket prohibition on pointer subtraction in
constant expressions and replaces it with a prohibition on operations
with undefined behavior, so this testcase ought to work. It wasn't
working because our internal representation of pointer subtraction
involves converting the
On Mon, 5 Dec 2011, Uros Bizjak wrote:
> Hello!
>
> Just skip these tests when -fno-fat-lto-objects was added to options.
>
> 2011-12-05 Uros Bizjak
>
> PR testsuite/51128
> * gcc.dg/torture/pr23821.c: Skip if -fno-fat-lto-objects was passed.
> * gcc.dg/torture/pr39074.c: Ditto
Oleg Endo wrote:
> If OK, I'd like to add some more verbose comments to sync.md, which also
> describe the ABI that is used for the atomic sequences. Just to have it
> in one place.
Sure. Such comments will be fine.
Regards,
kaz
On Mon, 2011-12-19 at 07:13 +0900, Kaz Kojima wrote:
> You are right. I've misunderstood your changes.
> Sorry for my mess.
Uhm, I could just have left the comments in the patch, but for some
mysterious reasons I deleted them before sending it :T
Sorry for that.
If OK, I'd like to add some more
Let's use tf_warning_or_error instead of tf_warning; I don't think we
ever pass tf_error without tf_warning, but we would want to check
narrowing in that case if we ever did. OK with that change.
Jason
Updated patch: I missed that the attr.pointer becomes attr.class_pointer
with the class container. I have updated the checks in resolve.c and
added a test case.
OK for the trunk?
Tobias
On 16.12.2011 22:10, Tobias Burnus wrote:
Dear all,
this patch fixes on of the FIXMEs in coarray/poly_r
Oleg Endo wrote:
> I know. That's what I was actually doing. Maybe I should have
> commented it, as it is not so obvious. The aligns are placed in such a
> way, that label 1 will always end up being 4-byte aligned.
You are right. I've misunderstood your changes.
Sorry for my mess.
> Having t
Hi,
today I was having a look to c++/50855: for the testcase therein
currently we are trying to just emit a "sorry, unimplemented: mangling
constructor" and bail out. This is actually the case in 4_6-branch. In
mainline, instead:
50855.C: In substitution of ‘template decltype ({256})
test(c
On 12/17/2011 10:36 PM, Chung-Lin Tang wrote:
> I don't think it's that kind of problem; the powerpc backend uses
> unlikely_text_section_p(), which compares the passed in argument section
> and the value of function_section_1(current_function_decl,true).
I think this might be the real bug, or som
This fixes a missed vectorization on platforms where fat pointers are passed by
reference (most 32-bit RISC architectures and x86-64/Windows).
Tested on i586-suse-linux, applied on the mainline.
2011-12-18 Eric Botcazou
* gcc-interface/decl.c (gnat_to_gnu_param): Add comment about d
On Sun, 18 Dec 2011, Georg-Johann Lay wrote:
> > This new file needs to have the standard copyright and license notices.
> > It's desirable to generate such notices in the output files as well.
>
> What is the right copyright for the generated files?
See other examples.
> avr/multilib.h is incl
On Sun, 2011-12-18 at 09:15 +0900, Kaz Kojima wrote:
> Your patch doesn't work because SH soft atomic sequences have
> another constraint that label 1 should have been 4-byte aligned.
I know. That's what I was actually doing. Maybe I should have
commented it, as it is not so obvious. The align
> This endian difference is the cause of the mips-sde-elf build failure
> that Maciej reported earlier in the week. Tested on that target and
> on x86_64-linux-gnu. OK to install?
>
> Richard
>
>
> gcc/
> * lower-subreg.c (can_decompose_p): Check every word of a hard
> register.
OK e
Jakub Jelinek wrote on 15/12/2011 03:51:25 PM:
> On Thu, Dec 15, 2011 at 03:35:34PM +0200, Ira Rosen wrote:
> > > This patch also fixes
> > > a problem where vect_determine_vectorization_factor would iterate the
> > same
> > > stmt twice - for some reason both the original stmt and pattern stmt
Since gcc silently accepts any -Wno-* flag on purpose, it is ineffective
to check for support of a warning flag using the negative form. Instead
always use the positive form when running the check (but keep the
original spelling for the result).
(Requires regeneration of fixincludes/configure gcc
> This patch fixes the specific problem in the test case by skipping over
> equivalences that would rewrite to exactly the same expression as on the
> current iteration. But, it's not clear that there can't also be cycles
> of length > 1. I don't see much point in getting fancy here (I assume
> t
Joseph S. Myers schrieb:
On Thu, 15 Dec 2011, Georg-Johann Lay wrote:
Index: gcc/config/avr/genmultilib.awk
===
--- gcc/config/avr/genmultilib.awk (revision 0)
+++ gcc/config/avr/genmultilib.awk (revision 0)
@@ -0,0 +1,2
> Here g++ is invoked without an absolute path, so if you have an older
> version of g++ in your path that does not grok -Wno-narrowing yet that
> will fail, won't it? I assume that's why only some like you and me are
> seeing this, but not all of us.
Yes, for some reason the base C++ compiler is
On Sat, 17 Dec 2011, Eric Botcazou wrote:
>> Putting into gcc/cp/config-lang.in is a layering violation, it's true. But
>> until there's another instance that needs handling, it seems premature to
>> build infrastructure to handle this. And it's only one line after all...
> I don't know exactly w
Hello world,
here is the reworked patch for improving function elimination.
It turned out to be much simpler than the original one.
Because real constants (and complex) constants are compared
for equality only, it should be pretty safe.
OK for trunk?
Thomas
2011-12-17 Thomas Koenig
Now that GNAT supports multilib configurations, it is possible to build a
32-bit Ada compiler on a biarch 64-bit system starting with the 64-bit
compiler, by adding -m32 to the configure variables CC, CXX, etc... except
that this miserably breaks for GNATBIND and GNATMAKE.
Fixed thusly, tested
On 18/12/11 09:47, Hans-Peter Nilsson wrote:
>> From: Hans-Peter Nilsson
>> Date: Sun, 18 Dec 2011 09:32:36 +0100
>
>> Typos like this cause the test-run to be aborted for the current
>> .exp file,
>
>> In this case, some 3000 test-cases went missing, judging by the
>> "gcc Summary" output.
>
>
> From: Hans-Peter Nilsson
> Date: Sun, 18 Dec 2011 09:32:36 +0100
> Typos like this cause the test-run to be aborted for the current
> .exp file,
> In this case, some 3000 test-cases went missing, judging by the
> "gcc Summary" output.
Correction: not just the .exp file but the whole dejagnu
i
> From: Tom de Vries
> Date: Thu, 15 Dec 2011 10:23:27 +0100
> bootstrapped and reg-tested (ada inclusive) on x86_64.
Time to update your inspection script: there's a missing sanity
check for the number of passes. I suggest you re-run regtests
for the main change with the below patch applied.
25 matches
Mail list logo
