> When I was looking at some LTO-related test failures last week (see mail
> on gcc@), I found that the many punctuation and grammatical errors in
> the -flto documentation made this section of the GCC manual hard to
> read. I made a pass over it to clean up the worst problems -- since the
> chang
These are "long long" on all supported platforms instead of the
default "long" on 64-bit, "long long" on 32-bit that defaults.h
assumes.
2012-01-03 Mark Kettenis
* config/openbsd-stdint.h (INTMAX_TYPE, UINTMAX_TYPE): New defines.
Index: gcc/config/openbsd-stdint.h
==
> AFAICT, we previously wanted to handle "restart safety" by adding
> abnormal edges to all calls to the TM runtime library (which could in
> turn call the libitm longjmp that actually restarts a transaction).
> Richard mentioned that we could drop this code (I think he meant this,
> and others pie
On Mon, 2 Jan 2012, Jakub Jelinek wrote:
> Hi!
>
> When gimple_ic is changing an indirect call into
> if (cond)
> direct_call ();
> else
> (*indirect_call) ()
> and the indirect_call is not noreturn, but direct_call is
> noreturn, we ICE during checking after profile, because the noreturn
> c
On Mon, 2 Jan 2012, Richard Guenther wrote:
>
> I am testing the following patch to fix PR51730.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
> Richard.
>
> 2012-01-02 Richard Guenther
>
> PR middle-end/51730
> * fold-const.c (fold_comparison): Proper
Applied to mainline.
2011-10-11 Andreas Krebbel
* config/s390/s390.md ("*cmp_ccs"): Fix comment mentioning
the instructions emitted by the pattern.
("*TDC_insn_"): Add comment.
---
gcc/config/s390/s390.md |3 +!!
1 file changed, 1 insertion(+), 2 modifications(!)
Hello,
> On Mon, Jan 2, 2012 at 3:30 PM, Richard Sandiford
> wrote:
> > Ayal Zaks writes:
> >> + for (i = 0; i < ira_pressure_classes_num; i++)
> >> + {
> >> + enum reg_class pressure_class;
> >> +
> >> + pressure_class = ira_pressure_classes[i];
> >> +
> >> + if (max_reg_pre
On Mon, Jan 2, 2012 at 8:00 PM, Richard Sandiford
wrote:
> Eric Botcazou writes:
>>> You are basically (but non-optimally) locally re-implementing
>>> what expr.c:get_object_or_type_alignment does, for the
>>> bare MEM_REF case (you don't consider offsets that
>>> do not change the alignment, nor
On Tue, Jan 3, 2012 at 5:53 AM, Hans-Peter Nilsson
wrote:
> All cross-builds are "still" done as C. In C++ you don't need
> the missing struct qualifier or the typedef in "typedef struct
> gfc_expr ... gfc_expr;" (the struct declaration suffices) as
> there's no separate struct namespace IIUC.
>
On Tue, Jan 3, 2012 at 9:36 AM, Eric Botcazou wrote:
>> AFAICT, we previously wanted to handle "restart safety" by adding
>> abnormal edges to all calls to the TM runtime library (which could in
>> turn call the libitm longjmp that actually restarts a transaction).
>> Richard mentioned that we cou
> If you have nested structure types that are TYPE_STRUCTURAL_EQUALITY
> then they have TYPE_CANONICAL == NULL_TREE and types_compatible_p
> will return false (it ICEd in previous releases I believe) and thus you
> won't stop attaching COMPONENT_REFs.
>
> So the fix isn't complete.
OK, I see. The
On Tue, Jan 3, 2012 at 11:16 AM, Eric Botcazou wrote:
>> If you have nested structure types that are TYPE_STRUCTURAL_EQUALITY
>> then they have TYPE_CANONICAL == NULL_TREE and types_compatible_p
>> will return false (it ICEd in previous releases I believe) and thus you
>> won't stop attaching COMP
On Tue, 2012-01-03 at 09:36 +0100, Eric Botcazou wrote:
> > AFAICT, we previously wanted to handle "restart safety" by adding
> > abnormal edges to all calls to the TM runtime library (which could in
> > turn call the libitm longjmp that actually restarts a transaction).
> > Richard mentioned that
This fixes another piece of PR51070 -
stmt_has_scalar_dependences_outside_loop was not handling calls.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-01-03 Richard Guenther
PR tree-optimization/51070
* tree-loop-distribution.c (stmt_has_scalar_
This fixes PR51692, we shouldn't remove the lhs of allocation
calls before the special malloc/free pair removal code kicks in.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-01-03 Richard Guenther
PR tree-optimization/51692
* tree-ssa-dce.c (eli
On Tue, 2012-01-03 at 10:41 +0100, Richard Guenther wrote:
> On Tue, Jan 3, 2012 at 9:36 AM, Eric Botcazou wrote:
> >> AFAICT, we previously wanted to handle "restart safety" by adding
> >> abnormal edges to all calls to the TM runtime library (which could in
> >> turn call the libitm longjmp that
On Mon, Jan 2, 2012 at 9:31 PM, Richard Henderson wrote:
> On 01/03/2012 06:47 AM, Uros Bizjak wrote:
>> if (d->testing_p)
>> return true;
>>
>> + hi = shift < nelt ? d->op1 : d->op0;
>> + lo = shift < nelt ? d->op0 : d->op1;
>> +
>> + shift %= nelt;
>
> This bit only works for little-e
Hi,
As described in PR 51269, the vectorizer adjusts number of prologue loop
iterations according to cost model, but never uses the result. This happens
because the result is not returned from the function that computes it, and
is, therefore, ignored.
Bootstrapped and tested on powerpc64-suse-li
> Sorry for the late notice, but this regressed memcpy-1.c for n32 and n64
> on mips64-linux-gnu. I realise memcpy-1.c isn't viewed as being a proper
> SRA test, but in this case I think it really is showing a genuine problem.
> We have:
>
> struct a {int a,b,c;} a;
> int test(struct a a)
On Mon, 2 Jan 2012, Jason Merrill wrote:
> On 01/02/2012 10:49 AM, Richard Guenther wrote:
> > For the idea creating the DIE at the point we process the limbo DIE
> > yes. But would you consider doing that unconditional or only for LTO?
>
> Unconditional. Anything that already passed the assert
> Shouldn't we go back and unconditionally return false if lhs and (or?) rhs
> are BLKmode? I suppose they are, in this case. Or should we truncate
> the alignment from get_object_alignment to TYPE_ALIGN if it is bigger
> than that to avoid this situation?
Sorry, I didn't read your message befor
Eric Botcazou writes:
>> Sorry for the late notice, but this regressed memcpy-1.c for n32 and n64
>> on mips64-linux-gnu. I realise memcpy-1.c isn't viewed as being a proper
>> SRA test, but in this case I think it really is showing a genuine problem.
>> We have:
>>
>> struct a {int a,b,c;} a
On Tue, Jan 3, 2012 at 12:26 PM, Eric Botcazou wrote:
>> Shouldn't we go back and unconditionally return false if lhs and (or?) rhs
>> are BLKmode? I suppose they are, in this case. Or should we truncate
>> the alignment from get_object_alignment to TYPE_ALIGN if it is bigger
>> than that to avo
pected passes20
# of unexpected failures12
# of unresolved testcases 1
# of unsupported tests 112
=== gcc Summary ===
# of expected passes50
# of unexpected failures14
# of unresolved testcases 2
# of unsupported tests 224
/home/uros/gcc-build/gcc/xgcc version 4.7.0 20120103 (experimental)
[trunk revision 182829] (GCC)
Uros.
On Jan 2, 2012, at 13:45 , Richard Guenther wrote:
> Ok.
Thanks Richard.
Hi!
Referring to malloced strings from GC hashtable macinfo_table entries
and then freeing them at the end of compilation process is problematic
with PCH, because without PCH the strings are malloced, but with PCH
ggc allocated after restore and thus free on them is invalid.
Fixed by making the s
On Tue, Jan 3, 2012 at 2:25 PM, Jakub Jelinek wrote:
> Hi!
>
> Referring to malloced strings from GC hashtable macinfo_table entries
> and then freeing them at the end of compilation process is problematic
> with PCH, because without PCH the strings are malloced, but with PCH
> ggc allocated after
Hi,
in this issue, filed by Martin Sebor and confirmed at the time by the
EDG people (indeed ICC accepts the testcase), we reject an array as
source v of a dynamic_cast, because we don't decay it to pointer, as we
should when T is a pointer type, per 5, p8 in C++03 about an lvalue
expression
The fix for PR49651 was too conservative as I noticed when trying
to backport it to the 4.5 branch. The following adjusts it to
preserve the optimization cases we have in the tree-ssa testsuite.
Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
Richard.
2012-01-03 Richard Guenther
On 12/23/11 03:31, Richard Guenther wrote:
On Thu, Dec 22, 2011 at 8:47 PM, Aldy Hernandez wrote:
The problem here is that with -fnon-call-exceptions, a memory dereference
may trap, but when we instrument the store, we have lost the landing pad
information.
One solution would be to move the EH
OK.
Jason
On 01/03/2012 08:25 AM, Jakub Jelinek wrote:
Hi!
Referring to malloced strings from GC hashtable macinfo_table entries
and then freeing them at the end of compilation process is problematic
with PCH, because without PCH the strings are malloced, but with PCH
ggc allocated after restore and thus
On Tue, Jan 03, 2012 at 10:22:05AM -0500, Patrick Marlier wrote:
> >@@ -20909,7 +20905,6 @@ output_macinfo (void)
> > if (!VEC_empty (macinfo_entry, files))
> > {
> > macinfo_entry *file = VEC_last (macinfo_entry, files);
> >- free (CONST_CAST (char *, file->info));
Hello world,
the attached patch fixes the PR by unconditionally disabling warnings
about unused variables in common blocks.
The reasons are outlined in the PR; there is quite a lot of unnecessary
clutter caused by common blocks in module interfaces.
Regression-tested. OK for trunk?
Th
When compiling with a compiler that is conformant to the c++11 spec for PR
c++/50500, std::shared_ptr must have an explicitly defined copy constructor.
Backported from revision 180159. The rest of the revision includes new
functionality, so only this part should be applied to 4.6. This has been
te
Fixing a typo when Cc'ing Matthias Klose.
---
When compiling with a compiler that is conformant to the c++11 spec for PR
c++/50500, std::shared_ptr must have an explicitly defined copy constructor.
Backported from revision 180159. The rest of the revision includes new
functionality, so only this
On 01/03/2012 01:18 AM, Eric Botcazou wrote:
When I was looking at some LTO-related test failures last week (see mail
on gcc@), I found that the many punctuation and grammatical errors in
the -flto documentation made this section of the GCC manual hard to
read. I made a pass over it to clean up
On 3 January 2012 16:23, Chase Douglas wrote:
> When compiling with a compiler that is conformant to the c++11 spec for PR
> c++/50500, std::shared_ptr must have an explicitly defined copy constructor.
This has already been fixed in GCC 4.7, see PR 50500
PR 51699 is another example of Clang faili
On 3 January 2012 16:59, Jonathan Wakely wrote:
> On 3 January 2012 16:23, Chase Douglas wrote:
>> When compiling with a compiler that is conformant to the c++11 spec for PR
>> c++/50500, std::shared_ptr must have an explicitly defined copy constructor.
>
> This has already been fixed in GCC 4.7, s
For the following testcase, we display indirect calls as memory
addresses, which can confuse the user:
struct list {
void (*compare)();
} *listPtr;
static void (*compare)();
__attribute__((transaction_safe))
static void func () {
listPtr->compare();
/* ^^ */
/* erro
On 01/03/2012 12:01 PM, Jonathan Wakely wrote:
> On 3 January 2012 16:59, Jonathan Wakely wrote:
>> On 3 January 2012 16:23, Chase Douglas wrote:
>>> When compiling with a compiler that is conformant to the c++11
>>> spec for PR c++/50500, std::shared_ptr must have an explicitly
>>> defined copy co
On 01/03/12 11:04, Aldy Hernandez wrote:
For the following testcase, we display indirect calls as memory
addresses, which can confuse the user:
struct list {
void (*compare)();
} *listPtr;
static void (*compare)();
__attribute__((transaction_safe))
static void func () {
listPtr->compare();
/* ^^
On 3 January 2012 17:13, Stephen M. Webb wrote:
> On 01/03/2012 12:01 PM, Jonathan Wakely wrote:
>> On 3 January 2012 16:59, Jonathan Wakely wrote:
>>> On 3 January 2012 16:23, Chase Douglas wrote:
When compiling with a compiler that is conformant to the c++11
spec for PR c++/50500, std::
On 01/03/2012 09:01 AM, Jonathan Wakely wrote:
> On 3 January 2012 16:59, Jonathan Wakely wrote:
>> On 3 January 2012 16:23, Chase Douglas wrote:
>>> When compiling with a compiler that is conformant to the c++11 spec for PR
>>> c++/50500, std::shared_ptr must have an explicitly defined copy constr
On 3 January 2012 18:07, Chase Douglas wrote:
> I rebuilt the library with this
> change to gcc and ran the test suite. All passed normally.
That's what I needed to know, your original mail didn't say anything
about running the test suite.
Looking at the patch again, why have you added destructor
Hi,
so this is what I did earlier today to add the missing bits to the
parser. The work turned out to be very easy, maybe too easy? ;) Is there
something I'm missing? I'm also adding a 'dg-do run' library testcase.
Booted and tested x96_64-linux.
Thanks,
Paolo.
///
/gcc/cp
2
Hello!
-mieee is needed for this runtime test to avoid
FAIL: gfortran.dg/typebound_operator_8.f03 -O0 execution test
FAIL: gfortran.dg/typebound_operator_8.f03 -Os execution test
on alpha-linux-gnu.
Probably underflow, or something exceptional, gdb is not a friend with
fortran code on this
On 01/03/2012 10:13 AM, Jonathan Wakely wrote:
> On 3 January 2012 18:07, Chase Douglas wrote:
>> I rebuilt the library with this
>> change to gcc and ran the test suite. All passed normally.
>
> That's what I needed to know, your original mail didn't say anything
> about running the test suite.
>
Hi!
My previous patch apparently wasn't enough. If at add_mem_*
time mem_elt is still its own canonical cselib_val, but only afterwards
new_elt_loc_list adds a new canonical cselib_val to it (and moves
over its locs), then we can still crash in cselib_invalidate_mem.
This patch ensures that new_e
When compiling with a compiler that is conformant to the c++11 spec for PR
c++/50500, std::shared_ptr must have an explicitly defined copy constructor.
Backported from revisions 180159 and 173882. The rest of the revisions include
new functionality, so only this part should be applied to 4.6.
Thi
OK.
Jason
On Mon, 2012-01-02 at 19:10 +0100, Torvald Riegel wrote:
> - Do we potentially get unnecessary warnings (if vars are live across
> a transaction begin)? I didn't get such warnings in the STAMP app
> that wasn't working though. Does anyone has suggestions for a test
> case?
Attached is a te
On 01/04/2012 04:18 AM, Aldy Hernandez wrote:
> PR middle-end/51696
> * trans-mem.c (diagnose_tm_1): Display indirect calls with no name
> correctly.
Ok.
r~
Dear All,
This is a straightforward patch that adds a last ditch attempt to find
a specific typebound procedure when all that has been found for a
derived type base object is 'deferred'. typebound_operator_7.f03 has
been extended to test derived type as well as class base objects.
Bootstrapped a
On 01/04/2012 01:10 AM, Aldy Hernandez wrote:
> I can certainly do this. I am however, waiting for the final approval. It
> wasn't clear whether that was an approval from Richard Henderson, or whether
> I should wait for an official ok.
>
> OK for mainline?
Yes, it was approval.
r~
On 3 January 2012 19:17, Chase Douglas wrote:
>
> PR c++/50500
> * include/bits/shared_ptr.h: Add lazy copy ops even if there's a move
That is the ChangeLog for the front-end part of 50500, isn't it?
Should be something like "Default copy ctor and assignment."
Otherwise this is OK to check in, th
On 01/03/2012 09:50 PM, Uros Bizjak wrote:
> I tried to investigate -mbig-endian a bit, but unfortunately almost
> all gcc.dg/torture/vshuf-*.c tests FAIL with -O2 on unpatched gcc.
> Tests pass with -O0, though.
Tests without -O don't actually test this code.
And -mbig-endian doesn't get big-end
Attached patch applied.
2012-01-03 François Dumont
* include/bits/hashtable_policy.h (_Ebo_helper<>): Rename to
the more
specific _Hashtable_ebo_helper. Hide this implementation detail
thanks
to private inheritance.
I was about to roll the ChangeLog but I saw that t
On 01/03/2012 12:34 PM, Jonathan Wakely wrote:
> On 3 January 2012 19:17, Chase Douglas wrote:
>>
>> PR c++/50500
>> * include/bits/shared_ptr.h: Add lazy copy ops even if there's a move
>
> That is the ChangeLog for the front-end part of 50500, isn't it?
> Should be something like "Default copy c
On 3 January 2012 20:45, Chase Douglas wrote:
> On 01/03/2012 12:34 PM, Jonathan Wakely wrote:
>> On 3 January 2012 19:17, Chase Douglas wrote:
>>>
>>> PR c++/50500
>>> * include/bits/shared_ptr.h: Add lazy copy ops even if there's a move
>>
>> That is the ChangeLog for the front-end part of 50500,
On 01/04/2012 06:14 AM, Jakub Jelinek wrote:
> PR bootstrap/51725
> * cselib.c (new_elt_loc_list): When moving locs from one
> cselib_val to its new canonical_cselib_val and the
> cselib_val was in first_containing_mem chain, but
> the canonical_cselib_val was not, add
On 01/03/2012 09:36 PM, François Dumont wrote:
I was about to roll the ChangeLog but I saw that there is already a
January entry in it so I keep on adding to the current one.
For the record, it's just that I was in a hurry, there is no plan behind
that.
Paolo.
On 01/03/12 14:01, Richard Henderson wrote:
On 01/04/2012 04:18 AM, Aldy Hernandez wrote:
PR middle-end/51696
* trans-mem.c (diagnose_tm_1): Display indirect calls with no name
correctly.
Ok.
r~
Sorry for the noise, but I forgot to check that we actually have a DECL
On 01/04/2012 08:19 AM, Aldy Hernandez wrote:
> PR middle-end/51696
> * trans-mem.c (diagnose_tm_1): Display indirect calls with no name
> correctly.
Ok.
r~
On Mon, Jan 2, 2012 at 1:06 PM, Jonathan Wakely wrote:
> libgcc/ChangeLog
> 2012-01-02 Jonathan Wakely
>
> PR bootstrap/51006
> * enable-execute-stack-mprotect.c (getpagesize): Do not define
> for NetBSD.
>
> This removes the definition of getpagesize which is always presen
I get testsuite failures with this change applied:
FAIL: 20_util/shared_ptr/cons/43820_neg.cc (test for errors, line 858)
FAIL: 20_util/shared_ptr/cons/43820_neg.cc (test for excess errors)
FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc (test for warnings, line 354)
FAIL: 20_util/weak_ptr/comparis
On 01/03/2012 01:38 PM, Jonathan Wakely wrote:
> I get testsuite failures with this change applied:
>
> FAIL: 20_util/shared_ptr/cons/43820_neg.cc (test for errors, line 858)
> FAIL: 20_util/shared_ptr/cons/43820_neg.cc (test for excess errors)
> FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc (tes
On 3 January 2012 21:48, Chase Douglas wrote:
> On 01/03/2012 01:38 PM, Jonathan Wakely wrote:
>> I get testsuite failures with this change applied:
>>
>> FAIL: 20_util/shared_ptr/cons/43820_neg.cc (test for errors, line 858)
>> FAIL: 20_util/shared_ptr/cons/43820_neg.cc (test for excess errors)
>
On 01/03/2012 09:42 PM, Torvald Riegel wrote:
>> Why does the explicit CFG approach not work exactly? cfun->calls_setjmp is
>> thought to be quite a big hammer.
>
> I don't know, actually. When I looked at the miscompilation case, all
> abnormal edges seemed to be in place.
>
> @rth: Do you ha
Dear Uros,
Thanks for that. It is not a problem that I encountered on either the
32 bit or 64 bit machines that I use but, as you say, an underflow is
the most likely explanation. I guess that without any loss, as far as
the test is concerned, a test that obj%c(i,j) is greater than 1e-5,
say, co
70 matches
Mail list logo
