Revision 183457 breaks bootstrap on darwin (pr51985).
TIA
Dominique
Hi!
The s390 glibc (_itoa function in particular) is miscompiled because
pcom pass changes:
__asm__("lr %N0,%1
mr %0,%2" : "=&r" __x.__ll : "r" ti_10, "r" s1_12);
__w1_15 = __x.__i.__h;
into:
__x___i___h_lsm0.28_34 = __x.__i.__h;
...
__asm__("lr %N0,%1
mr %0,%2" : "=&r" __x
Hi!
On powerpc64-linux the ext-elim-1.c testcase started failing,
becuase we have there an insn with a sign (or was it zero?) extension
in a parallel with setting flags. Via note_stores it happily accepts
the insn as an candidate, but later on assumes the sign extension
must be right in the insn
Hi,
composite_type doesn't consider the pointer mode when creating a pointer.
As a consequence:
type char *p32 __attribute__((mode (SI));
type char *p32 __attribute__((mode (SI));
creates a 64-bit pointers (on ia64-hp-openvms and certainly some other
configuration).
This breaks some compiler bu
On Wed, 25 Jan 2012, Jakub Jelinek wrote:
> Hi!
>
> The s390 glibc (_itoa function in particular) is miscompiled because
> pcom pass changes:
> __asm__("lr %N0,%1
> mr %0,%2" : "=&r" __x.__ll : "r" ti_10, "r" s1_12);
> __w1_15 = __x.__i.__h;
> into:
> __x___i___h_lsm0.28_34 = __x.__
Richard Henderson writes:
>> The eh-1.o reference to _Unwind_Resume drags in one copy of the unwinder
>> from libgcc_eh.a, while libstdc++.so is linked against libgcc_s.so.1,
>> providing another copy.
>
> So... are we linking with the gcc binary, not the g++ binary?
Right. This was just copied
On Wed, Jan 25, 2012 at 12:16 AM, Aldy Hernandez wrote:
> The problem here is that -flto cannot equate the instrumentation functions
> being generated with a user supplied version of the library functions. This
> would happen if the user tried to link a transactional program with libitm
> with -f
Hello,
this patch adds required support for thiscall/fastcall
calling-convention of x86 Windows. It is a prerequisit for fixing PR
libgcj/51500 for 32-bit Windows. The default-calling-convention for
C++ none-static and none-variadic class-members is changed by 4.7 to
thiscall as described by ven
On Wed, Jan 25, 2012 at 10:49:27AM +0100, Richard Guenther wrote:
> I wonder if it's worth handling asms in any fancy way here, considering
> that data-ref analysis happily punts on them completely. Thus, why
> not change the above to
>
> || stmt_code == GIMPLE_ASM)
I think asm ("..." : "+r" (
This patch renames the named address spaces from their initial draft names to
their final names as proposed by several developers, amongst them Eric.
* Using __flash will make porting to/from other compilers easier.
* "__flash" is more descriptive than the meaningless "__pgm".
* __pgm might lead t
On Wed, 25 Jan 2012, Jakub Jelinek wrote:
> On Wed, Jan 25, 2012 at 10:49:27AM +0100, Richard Guenther wrote:
> > I wonder if it's worth handling asms in any fancy way here, considering
> > that data-ref analysis happily punts on them completely. Thus, why
> > not change the above to
> >
> > |
Hello,
In this PR data dependence analysis goes wild by trying to process >20k
datarefs, so the patch limits the number of datarefs per loop we handle to
1000 via a param. On the way find_data_references_in_loop is made static
and predcom/parloops are fixed for compute_data_dependences_for_lo
Hello,
This patch fixes another problem with sel-sched not happy having bbs with
zero successors. Bootstrapped and tested on x86_64/linux.
Again, this is not a regression as __builtin_unreachable did not exist
before sel-sched, but the patch is very safe and obvious. It is my fault
not com
2012/1/25 Andrey Belevantsev :
> Hello,
>
> In this PR data dependence analysis goes wild by trying to process >20k
> datarefs, so the patch limits the number of datarefs per loop we handle to
> 1000 via a param. On the way find_data_references_in_loop is made static
> and predcom/parloops are fix
2012/1/25 Andrey Belevantsev :
> Hello,
>
> This patch fixes another problem with sel-sched not happy having bbs with
> zero successors. Bootstrapped and tested on x86_64/linux.
>
> Again, this is not a regression as __builtin_unreachable did not exist
> before sel-sched, but the patch is very saf
On 25.01.2012 16:38, Richard Guenther wrote:
2012/1/25 Andrey Belevantsev:
Hello,
In this PR data dependence analysis goes wild by trying to process>20k
datarefs, so the patch limits the number of datarefs per loop we handle to
1000 via a param. On the way find_data_references_in_loop is made
Second, it seems that by design, LTO prefers builtins to user-provided
versions of them. In particular, lto_symtab_prevailing_decl() stipulates
that builtins are their own prevailing decl. So even if we lowered TM
before LTO streaming, user provided builtins wouldn't be preferred (and thus
inl
On 01/24/12 17:24, Richard Henderson wrote:
On 01/25/2012 10:16 AM, Aldy Hernandez wrote:
The attached patch fixes the ICE in the PR, though it won't do what
the user ultimately wants to do, given the limitations described.
Perhaps we could create another PR and tag it with an enhancement
reques
The new test gcc.dg/tm/lto-1.c fails in configurations where lto support is
disabled.
This patch adds the missing target requirement to the test:
/* { dg-require-effective-target lto } */
Checked on qemu for arm-none-eabi configured with and without --disable-lto.
gcc/testsuite/ChangeLog
2012-
VN ops comparison code value-numbers
VIEW_CONVERT_EXPR(__thing_31).._M_node
and
__thing_31->_M_node
the same because it fails to check for *__thing_31 vs. __thing_31.
Bootstrap & regtest pending on x86_64.
Richard.
2012-01-25 Richard Guenther
* tree-ssa-sccvn.c (vn_reference
On 25.01.2012 06:26, Benjamin Kosnik wrote:
this breaks builds configured with --enable-libstdcxx-debug.
confirmed
Tried
the following (not yet working) fix.
OK. The attached is closer, but still not quite there.
one step further, to avoid the endless recursion in the install-debug t
2012/1/25 Andrey Belevantsev :
> On 25.01.2012 16:38, Richard Guenther wrote:
>>
>> 2012/1/25 Andrey Belevantsev:
>>>
>>> Hello,
>>>
>>> In this PR data dependence analysis goes wild by trying to process>20k
>>> datarefs, so the patch limits the number of datarefs per loop we handle
>>> to
>>> 1000
On Wed, Jan 25, 2012 at 2:00 PM, Aldy Hernandez wrote:
>
>>> Second, it seems that by design, LTO prefers builtins to user-provided
>>> versions of them. In particular, lto_symtab_prevailing_decl() stipulates
>>> that builtins are their own prevailing decl. So even if we lowered TM
>>> before LT
On 01/25/12 08:23, Richard Guenther wrote:
On Wed, Jan 25, 2012 at 2:00 PM, Aldy Hernandez wrote:
Second, it seems that by design, LTO prefers builtins to user-provided
versions of them. In particular, lto_symtab_prevailing_decl() stipulates
that builtins are their own prevailing decl. So e
On Wed, Jan 25, 2012 at 3:27 PM, Aldy Hernandez wrote:
> On 01/25/12 08:23, Richard Guenther wrote:
>>
>> On Wed, Jan 25, 2012 at 2:00 PM, Aldy Hernandez wrote:
>>>
>>>
> Second, it seems that by design, LTO prefers builtins to user-provided
> versions of them. In particular, lto_symtab_
The test gcc.target/arm/di-longlong64-sync-withldrexd.c fails on
arm-none-eabi target, because gcc generates 48 LDREXD and 48 STREXD
instructions instead of the expected 46.
FAIL: gcc.target/arm/di-longlong64-sync-withldrexd.c scan-assembler-times
tldrexd 46
FAIL: gcc.target/arm/di-longlong64-sync
On Wed, Jan 25, 2012 at 01:18:28PM +0100, Richard Guenther wrote:
> Yes, that's ok with me. For the rest you can file an enhancement PR.
Ok, here is what I've committed, and I'll file the PR momentarily.
2012-01-25 Jakub Jelinek
PR tree-optimization/51987
* tree-data-ref.c (g
when setting sysroot to / (for whatever reason), then search directories and
headers start with a double-slash, as seen with gcc -v.
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/4.6/include
//usr/local/include
/usr/lib/gcc/x86_64-linux-gn
Hi,
so, the below adjusted testcase from PR48794 still fails for the same
reasons (regions still referenced from RESX being removed). I was split
minds about if that's a new bug or just an extension of the old bug, so I
hijacked the old PR. In any case, remove_unreachable_handlers_no_lp needs
On 25/01/12 14:10, Greta Yorsh wrote:
> The new test gcc.dg/tm/lto-1.c fails in configurations where lto support is
> disabled.
>
> This patch adds the missing target requirement to the test:
> /* { dg-require-effective-target lto } */
>
> Checked on qemu for arm-none-eabi configured with and wi
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01020.html
Georg-Johann Lay wrote:
> Adding AVR-specific release notes to wwwdocs/htdocs/gcc-4.7/changes.html
>
> Ok?
>
> Johann
>
Hi!
Apparently $(inst_sources) is included in libc__98convenience_la_SOURCES and
libc__98_la_SOURCES twice, once directly, once through $(host_sources_extra)
included in $(sources). On x86_64-linux and others it causes just lots
of bloat (libstdc++.a is much bigger, as several objects are there t
Hi,
On Wed, 25 Jan 2012, Michael Matz wrote:
> so, the below adjusted testcase from PR48794 still fails for the same
> reasons (regions still referenced from RESX being removed). I was split
> minds about if that's a new bug or just an extension of the old bug, so
> I hijacked the old PR. In
The problem here turns out to be that when free_lang_data_in_cgraph
tries to find all the decls and types in a function, it doesn't catch a
type that only appears in the fntype of a GIMPLE_CALL. This patch fixes
the bug; is there a better way to handle it?
Tested x86_64-pc-linux-gnu, OK for t
On Wed, 25 Jan 2012, Tristan Gingold wrote:
> 2012-01-25 Tristan Gingold
>
> * c-typeck.c (composite_type): Keep mode for pointers.
OK.
--
Joseph S. Myers
jos...@codesourcery.com
On Wed, Jan 25, 2012 at 11:29:58AM -0500, Jason Merrill wrote:
> The problem here turns out to be that when free_lang_data_in_cgraph
> tries to find all the decls and types in a function, it doesn't
> catch a type that only appears in the fntype of a GIMPLE_CALL. This
> patch fixes the bug; is the
Dear all,
seemingly it can sometimes happen that "fclass" gets created but the
fclass->f2k_derived is not set. This patch now sets it explicitly, if unset.
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
PS: I am still looking for someone to review my rather straight-forward
p
On 01/23/2012 06:32 AM, Igor Zamyatin wrote:
Unfortunately patch doesn't help neither for separate EEMBC_2_0 tests
nor for the whole benchmark.
Do you want me to do some debugging here?
For now I am out of ideas how to fix the PR in alternative way without
some performance degradation on SPEC
On Wed, 25 Jan 2012, Matthias Klose wrote:
> This can end up in generation for dependency files, and other files parsing
> the output. The solution I came up with is to check for sysroot set to '/' and
> special case this in two places. Afaics, there are no other places.
I could imagine a sysroot
On 25/01/2012 03:27, Rafael Ávila de Espíndola wrote:
> Sorry, one more case that gcc accepts where it is not clear what the
> result should be:
>
> -
> #pragma GCC visibility push(protected)
>
> int x;
> class __attribute__((visibility("hidden"))) foo {
> static i
Dear Tobias,
On Wed, Jan 25, 2012 at 5:38 PM, Tobias Burnus wrote:
> Dear all,
>
> seemingly it can sometimes happen that "fclass" gets created but the
> fclass->f2k_derived is not set. This patch now sets it explicitly, if unset.
>
> Build and regtested on x86-64-linux.
> OK for the trunk?
OK f
> -Original Message-
> From: Georg-Johann Lay [mailto:a...@gjlay.de]
> Sent: Wednesday, January 25, 2012 4:02 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Denis Chertykov; Weddington, Eric; Joerg Wunsch
> Subject: [Patch,AVR]: Rename address spaces
>
> This patch renames the named address spac
As Georg-Johann Lay wrote:
> Ok for trunk?
Fine with me, too!
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
On Jan 25, 2012, at 7:35 AM, Greta Yorsh wrote:
> The test gcc.target/arm/di-longlong64-sync-withldrexd.c fails on
> arm-none-eabi target, because gcc generates 48 LDREXD and 48 STREXD
> instructions instead of the expected 46.
>
> FAIL: gcc.target/arm/di-longlong64-sync-withldrexd.c scan-assemble
Hi,
the following patch fixes a bootstrap issue for libjava (compile of
verify.cc ICEs). It is caused by the assumption that a GIMPLE_COND
lhs side has always a type. This isn't necessarily true, but it has
by default boolean_type_node as type.
ChangeLog
2012-01-25 Kai Tietz
* tre
On 25 January 2012, at 18:14, Mike Stump wrote:
> On Jan 25, 2012, at 7:35 AM, Greta Yorsh wrote:
> > The test gcc.target/arm/di-longlong64-sync-withldrexd.c fails on
> > arm-none-eabi target, because gcc generates 48 LDREXD and 48 STREXD
> > instructions instead of the expected 46.
> >
> > FAIL: g
This patch to the Go frontend always lowers subexpressions of lowered
expressions. This ensures that all parts of an expression are lowered.
Without this change, comparisons of struct fields embedded within
structs were not handled correctly. They would be passed to the backend
as an EQ_EXPR of t
This patch adds dg-require-time to tests that require a system clock
and dg-require-fileio to tests that perform file I/O.
Tested on mipsisa64-elf and applied as (I hope) obvious.
Richard
libstdc++-v3/
* testsuite/20_util/system_clock/1.cc: Add dg-require-time.
* testsuite/22_lo
> "Jakub" == Jakub Jelinek writes:
Jakub> Well, even bad debugging experience problems would be very undesirable
Jakub> if we generated wrong debug info and everybody compiled it into their
Jakub> sources. But pretty-printers stay on the side, it is just a matter of
Jakub> updating the pytho
The testcase for PR 51933 was failing on mipsisa64-elf because md_reorg
changed a symbolic small-data asm operand into a LO_SUM.
Tested on mipsisa64-elf and applied.
Richard
gcc/
* config/mips/mips.c: Don't process ASM_OPERANDS.
Index: gcc/config/mips/mips.c
===
Hi,
> Tested on mipsisa64-elf and applied as (I hope) obvious.
Sure obvious, in this case. In general, when tweaking the testsuite with the
goal of disabling some tests, I would recommend also double checking that
nothing gets inadvertently disabled on different targets, eg, run the testsuite
I somehow missed a few test lines in the updated Go testsuite, causing
the tests to be marked as unsupported. This patch updates the driver to
handle them. Fortunately they all pass. Ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
2012-01-25 Ian Lance Taylor
Richard Sandiford writes:
> Alexandre Oliva writes:
>> On Nov 25, 2011, Jakub Jelinek wrote:
>>> The numbers I got with your patch (RTL checking) are below, seems
>>> the cumulative numbers other than 100% are all bigger with patched stage2,
>>> which means unfortunately debug info quality degra
This patch fixes PR51374 by more strictly updating mem_last_set.
Sloppy handling of mem_last_set can lead to error in volatile correctness
because combine then is allowed to drag one volatile access over an other
volatile thing (volatile access, asm volatile, unspec_volatile...).
As explained in t
On 01/26/2012 12:36 AM, Aldy Hernandez wrote:
> I would like another approval, just in case you disagree with the way I
> changed the dummy declarations in the LTO testsuite.
Still ok.
r~
Hi!
This PR is about a warning that rev may be used uninitialized when
sched_get_condition_with_rev_uncached is inlined into its caller.
It in fact may be used uninitialized if PATTERN (insn) is ever NULL.
But IMNSHO everything in the compiler assumes that PATTERN of an insn
is always non-NULL, so
Richard Sandiford writes:
> The testcase for PR 51933 was failing on mipsisa64-elf because md_reorg
> changed a symbolic small-data asm operand into a LO_SUM.
>
> Tested on mipsisa64-elf and applied.
>
> Richard
>
>
> gcc/
> * config/mips/mips.c: Don't process ASM_OPERANDS.
...now with adde
PR18589 identifies missed optimization opportunities for multiplies with
repeated factors, whether explicitly repeated or produced by a
__builtin_pow or __builtin_powi call. This patch, proposed for 4.8,
expands such built-in calls to expose the base factors, pre-multiplies
repeated factors togeth
Hi!
As detailed in the PR, when copy_decls_walk uses clone_tree,
it enters just the clone node of tag into the hash table and not
any children. On the testcase in that PR this DIE (DW_TAG_subroutine_type)
contains DW_AT_object_pointer attribute which refers to its child node
(DW_TAG_formal_parame
On 01/25/2012 03:10 PM, Jakub Jelinek wrote:
Hi!
This PR is about a warning that rev may be used uninitialized when
sched_get_condition_with_rev_uncached is inlined into its caller.
It in fact may be used uninitialized if PATTERN (insn) is ever NULL.
But IMNSHO everything in the compiler assumes
Dear all, dear Paul,
Dominique pointed out that the patch does not fully work and that one
gets an ICE:
internal compiler error: in gfc_release_symbol, at fortran/symbol.c:2531
For some odd reason, it didn't occur for my build, which had some
unrelated patch applied. I have not understood w
On 01/26/2012 02:35 AM, Greta Yorsh wrote:
> Before the change, __sync_lock_release expanded into STRD, storing DI value 0.
The most important question is: Is STRD guaranteed to perform the store
atomically? (And conversely, does LDRD perform the load atomically?)
If so (even for a subset of arc
I have committed a patch to update libgo to the weekly.2012-01-15
release. As usual I have not included the entire patch in this e-mail
message, just the changes to files that are specific to gccgo.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r
On 01/26/2012 05:44 AM, Kai Tietz wrote:
> the following patch fixes a bootstrap issue for libjava (compile of
> verify.cc ICEs). It is caused by the assumption that a GIMPLE_COND
> lhs side has always a type. This isn't necessarily true, but it has
> by default boolean_type_node as type.
A perf
On Wed, Jan 25, 2012 at 12:58 PM, Richard Henderson wrote:
> On 01/26/2012 05:44 AM, Kai Tietz wrote:
>> the following patch fixes a bootstrap issue for libjava (compile of
>> verify.cc ICEs). It is caused by the assumption that a GIMPLE_COND
>> lhs side has always a type. This isn't necessarily
On Wed, Jan 25, 2012 at 09:27:51PM +0100, Tobias Burnus wrote:
> Dear all, dear Paul,
>
> Dominique pointed out that the patch does not fully work and that one
> gets an ICE:
> internal compiler error: in gfc_release_symbol, at fortran/symbol.c:2531
>
> For some odd reason, it didn't occur for
I have committed a patch to libgo to update to the weekly.2012-01-20
release. As usual this e-mail message only includes changes to files
specific to gccgo. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r dd654495ccfb libgo/MERGE
--- a/libgo/ME
On 01/26/2012 03:04 AM, Michael Matz wrote:
> Actually, resx/eh_dispatch always are the last BB statements, so the loop
> doesn't need to look at all statements in a BB, making it quite somewhat
> faster. Consider the tree-eh.c to be looking like so:
For the record, is this without optimization
Steve Kargl wrote:
On Wed, Jan 25, 2012 at 09:27:51PM +0100, Tobias Burnus wrote:
I will commit it as "obvious" after it regtesting it.
JFYI, the patch fixes the ICE.
Yes, it does - and it also regtested. I committed it as Rev. 183541.
Tobias
On 01/25/2012 01:30 PM, Patrick Marlier wrote:
> From my point of view, no. When it is a thread local, it should not
> be shared to someone else. If the thread dies, what happens to the
> thread local variable? Should it be discarded completely and this
> piece of memory never reallocated? Even if
I committed a patch to remove a couple of object files from the Go
testsuite. I committed this by accident--they should not have gone in.
Dtest/bench/go1/_testmain.6
Dtest/bench/go1/_gotest_.6
Ian
I have merged trunk revision 183540 to the gccgo branch.
Ian
> And it's entirely likely that I'd thought of exactly that two years
> ago when the DECL_THREAD_LOCAL test was omitted from that bit of code,
> but I failed to add a comment.
>
> I guess this patch needs to be reverted...
It may be still a valid optimization, but only if you know there
is no esc
This libgo patch corrects a typo in mksysinfo.sh. Bootstrapped and ran
Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r b0964b26024e libgo/mksysinfo.sh
--- a/libgo/mksysinfo.sh Wed Jan 25 13:47:12 2012 -0800
+++ b/libgo/mksysinfo.sh Wed Jan 25 17:06:38 2012 -0800
@@
I've merged trunk revision 183549 onto the gccgo branch.
Ian
I'd like to add these new DW_AT and DW_FORM codes for the Fission project:
http://gcc.gnu.org/wiki/DebugFission
We're currently working on the Fission implementation in GCC, gold,
and binutils, but I'd like to at least lay claim to the actual values
to prevent overlap with any other extensions
Hi, David and Rong, thanks a lot! Modified code uploaded as patch 8
and is also included at the end of email body.
Ref - http://codereview.appspot.com/5461043
Regards,
-Han
== Patch start
diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index 6d31e90..131c1b9 100644
--- a/gcc/cfgexpand.c
+++ b
This change fixes some problems in reconstructing the identifier bindings.
In particular, it removes extra binding creations, handle new bindings better,
identifies already present bindings, and adds some assertions.
Improve debug dump for bindings.
One old test is now passing. One old test is 2
ok for google branches with the above changes. Please continue to seek
upstream approval.
David
http://codereview.appspot.com/5461043/diff/19001/gcc/doc/invoke.texi
File gcc/doc/invoke.texi (right):
http://codereview.appspot.com/5461043/diff/19001/gcc/doc/invoke.texi#newcode403
gcc/doc/invoke.
The GNU/Linux specific support in the net package uses the constant
IPV6_TCLASS. This patch to libgo/mksysinfo.sh ensures that the constant
is defined even on older GNU/Linux systems. Bootstrapped on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 2a1bceb2bd18 libgo/mksysinfo.sh
-
I have now merged trunk revision 183552 onto the gccgo branch.
Ian
81 matches
Mail list logo
