Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian at radakovits dot se
Target Milestone: ---
Created attachment 60825
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107745
--- Comment #5 from Sebastian "spaetz" Spaeth ---
I fully understand that nobody wants to invest time into fixing this. What
would be nice though, is if this were really just a missed optimization and not
rejecting to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107745
--- Comment #2 from Sebastian "spaetz" Spaeth ---
(sid_ppc64el-dchroot)~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64le-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARG
IRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Sebastian at SSpaeth dot de
Target Milestone: ---
TL;DR:
This looks like a compiler bug or quality-of-implementation issue, and happens
JUST ON PPC with gcc. F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480
--- Comment #2 from seberg ---
I still owed the correct example: https://godbolt.org/z/33Pj6xvPr
Now I think the cause is the indeed (somewhat understandandable) desire to
optimize away the branching. And not the instruction (I am not sure how
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480
--- Comment #1 from seberg ---
Actually, I think I likely misanalyzed, the actual code in question where I
found this was doing something like:
while (n--) {
if (isnan(*input)) {
*out = 1;
}
else {
*out = (long
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian-gcc at sipsolutions dot net
Target Milestone: ---
Compiling for ppc64le with `-O3` seems to use the `xvcmpgedp` instruction which
ends up setting the FPE flags. I have created an example in godbolt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100788
--- Comment #11 from seberg ---
Does that mean that fixing the `#line` directives (or inserting additional
ones) should be able to fix the issue? (Or work around it, if you consider it
a bug.)
I tried to figure out where the `#line` directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100788
--- Comment #9 from seberg ---
NumPy is pretty light weight (at least on linux systems, and if you do not care
about setting up BLAS manually). You probably only need the Python dev
headers, that I expect you already have.
Hopefully, the follo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100788
--- Comment #7 from seberg ---
Oh, interesting. You are right, if I run it on the preprocessed file it
succeeds (note the `tmp/preprocessed.c`:
x86_64-linux-gnu-gcc -pthread --coverage -O0 -ggdb -g
-ffile-prefix-map=/build/python3.9-RNBry6/pyt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100788
--- Comment #5 from seberg ---
> Now I miss the command line.
Do you mean more than the failing call?:
x86_64-linux-gnu-gcc -pthread --coverage -O0 -ggdb -g
-ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=.
-fstack-protector-strong -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100788
--- Comment #3 from seberg ---
Created attachment 50878
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50878&action=edit
actual_preprocessed_with_gcc
Sorry, I think this is what you are looking for now, adding -E to it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100788
--- Comment #1 from seberg ---
Created attachment 50875
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50875&action=edit
preprocessed_file
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian-gcc at sipsolutions dot net
CC: marxin at gcc dot gnu.org
Target Milestone: ---
I first thought this might have been the identical issue as
https://gcc.gnu.org/bugzilla/show_bug.cgi
On Fri, Feb 4, 2011 at 00:27, dirtyepic at gentoo dot org
wrote:
> I'm guessing that means 4.5 will stay broken?
>
Depends on how difficult it would be to backport the fix.
I haven't git-bisect'ed it to know which of the patches fixed it.
>> access_fn_A: {0, +, 1}_1
>> access_fn_B: {0, +, 1}_2
>>
>> (subscript
>> iterations_that_access_an_element_twice_in_A: [0 + 1 * x_1]
>> last_conflict: 1000
>> iterations_that_access_an_element_twice_in_B: [0 + 1 * x_1]
>
> I think that this representation of affine functions is wrong:
> th
Here is the loop kernel from block-0.c
for (i = 0; i < N; i++)
for (j = 0; j < N; j++)
a[j] = a[i] + 1;
On Fri, Dec 31, 2010 at 06:01, jakub at gcc dot gnu.org
wrote:
> access_fn_A: {0, +, 1}_1
> access_fn_B: {0, +, 1}_2
>
> (subscript
> iterations_that_access_an_element_twice_in
We do bootstrap on amd64-linux the graphite branch for every
commit, and that would be the equivalent of your patch.
Please open a new bug for tracking this issue.
Thanks,
Sebastian
Here is the backported patch that fixes the ICE.
I will further test this and will post to gcc-patches.
Sebastian
From 8f0cc975c09d2e0779f7e25a82a295f3deb9de46 Mon Sep 17 00:00:00 2001
From: Sebastian Pop
Date: Fri, 5 Nov 2010 13:15:25 -0500
Subject: [PATCH] Fix PR45314: backport revision 163123
On Fri, Nov 5, 2010 at 11:26, hjl.tools at gmail dot com
wrote:
> On trunk, it was fixed by revision 163123:
>
> http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00334.html
>
Thanks HJ for reducing this.
I looked at this change and it looks simple enough to backport it to 4.5.
--- Comment #4 from sebastian dot huber at embedded-brains dot de
2010-09-10 15:59 ---
(In reply to comment #3)
> >For volatile fields we should use accesses of the appropriate width.
>
> The PowerPC ABI has specific rules for accessing volatile bitfields and IIRC
>
--- Comment #2 from sebastian dot huber at embedded-brains dot de
2010-09-10 15:43 ---
(In reply to comment #1)
> >1. index is constant or variable, and
>
> Yes that is correct.
>
> >2. the 'bar' field type.
>
> The alignment of the access is
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot huber at embedded-brains dot de
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GC
--- Comment #18 from sebastian dot huber at embedded-brains dot de
2010-08-12 08:19 ---
This bug is still present in GCC 4.6.0 20100807 (arm-eabi-gcc -O1
-fschedule-insns2 -mthumb):
readStream:
push{r4, lr}
sub sp, sp, #8
mov r4, sp
mov
These previous patches don't seem to solve the problem:
here is another reduced case that still fails in resolve_equivalence
at a different place than before.
$ cat bug.f
CALL TRFWTM(JKT,XX,NX,Y,NIX,NORB2,1,TOL)
IF(DBUG.AND.NX.GT.0) THEN
EQUIVALENCE (DBUGME, DBUGME_STR)
--- Comment #12 from sebastian dot huber at embedded-brains dot de
2010-06-24 12:49 ---
(In reply to comment #11)
[...]
> I'll get this and Bug 44647 done for 4.6.0
Please have a look at Bug 43863 also.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852
--- Comment #9 from sebastian dot huber at embedded-brains dot de
2010-06-24 10:09 ---
Created an attachment (id=20995)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20995&action=view)
Implementation, configure and documentation
Sorry, the config.h.in was
--- Comment #7 from sebastian dot huber at embedded-brains dot de
2010-06-24 09:41 ---
Created an attachment (id=20993)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20993&action=view)
Implementation, configure and documentation
Is libstdc++-v3/doc/xml/manual/configure.
--- Comment #4 from sebastian dot huber at embedded-brains dot de
2010-06-23 15:20 ---
Created an attachment (id=20987)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20987&action=view)
Moves std::bad_alloc implementation into new file bad_alloc.cc
I don't know how t
--- Comment #2 from sebastian dot huber at embedded-brains dot de
2010-06-23 15:02 ---
(In reply to comment #1)
> (In reply to comment #0)
> > The std::bad_alloc definitions should be placed into a
> > separate file.
>
> IIUC that wouldn't work, is require
are coupled
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot huber at embedded-brains dot de
http
--- Comment #17 from sebastian dot huber at embedded-brains dot de
2010-06-10 07:13 ---
Thank you for your investigations. A special case fix is better than nothing.
I am not a GCC expert but it seems that this kind of bug appears quite
regularly on different platforms and all use
--- Comment #14 from sebastian dot huber at embedded-brains dot de
2010-05-17 09:04 ---
This bug is present since r130052 which is related to:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01814.html
If this is a generic bug or not is quite irrelevant since this is a very
serious bug
--- Comment #11 from sebastian dot huber at embedded-brains dot de
2010-05-13 09:50 ---
Created an attachment (id=20654)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20654&action=view)
Difference between bdbuf.s in revsions 130051 and 130052
This clearly shows how th
--- Comment #10 from sebastian dot huber at embedded-brains dot de
2010-05-13 09:42 ---
Binary search through trunk revisions yield:
r159321 BROKEN
r15 BROKEN
r14 BROKEN
r135000 BROKEN
r132500 BROKEN
r131024 BROKEN
r130512 BROKEN
r130256 BROKEN
r130128 BROKEN
r130064 BROKEN
--- Comment #8 from sebastian dot huber at embedded-brains dot de
2010-05-12 12:03 ---
A summary follows. Broken means bdbuf.i generates an invalid stack frame usage
sequence in a function epilogue. Works means that the corresponding area is
valid.
Flags: -march=armv5t -mthumb -Os
--- Comment #7 from sebastian dot huber at embedded-brains dot de
2010-05-12 11:13 ---
GCC 4.3.2 20080827 has this problem too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
--- Comment #6 from sebastian dot huber at embedded-brains dot de
2010-05-12 11:06 ---
If you use GCC 4.5.0 20100414 with '-march=armv7' '-mthumb' '-Os' the function
epilogue is also correct. It seems that this is a Thumb 1 problem.
--
http://gcc.gn
--- Comment #5 from sebastian dot huber at embedded-brains dot de
2010-05-12 10:03 ---
GCC 4.2.4 does not have this problem.
Function epilogue:
.L672:
ldr r0, [r7, #4]
mov sp, r7
add sp, sp, #52
@ sp needed for prologue
pop {r4
--- Comment #4 from sebastian dot huber at embedded-brains dot de
2010-05-12 09:40 ---
GCC 4.5.0 20100414 has this problem too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
--- Comment #3 from sebastian dot huber at embedded-brains dot de
2010-05-12 07:22 ---
Created an attachment (id=20643)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20643&action=view)
Generated assembler file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
--- Comment #2 from sebastian dot huber at embedded-brains dot de
2010-05-12 07:21 ---
Created an attachment (id=20642)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20642&action=view)
Preprocessed source file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
--- Comment #1 from sebastian dot huber at embedded-brains dot de
2010-05-12 07:21 ---
Created an attachment (id=20641)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20641&action=view)
Log.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
dot org
ReportedBy: sebastian dot huber at embedded-brains dot de
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: arm-rtems4.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
--- Comment #6 from sebastian dot huber at embedded-brains dot de
2010-04-23 10:59 ---
(In reply to comment #5)
> Simply removing this class now would break the ABI, which is not acceptable.
> If Bug 43852 was resolved by adding a "quiet" mode, would that make th
--- Comment #3 from sebastian dot huber at embedded-brains dot de
2010-04-23 09:28 ---
(In reply to comment #2)
> In Bug 43852 I thought you meant building with -fno-exceptions fails, but it
> works for me ... do you just mean the resulting library is not as small as it
>
--- Comment #5 from sebastian dot huber at embedded-brains dot de
2010-04-23 09:20 ---
Created an attachment (id=20471)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20471&action=view)
Lets call it quiet.
Configure option may be --enable-quiet-cxx.
--
http://gcc.
--- Comment #4 from sebastian dot huber at embedded-brains dot de
2010-04-23 09:16 ---
Bug report for 1. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43863.
Bug report for 2. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43865
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852
--- Comment #1 from sebastian dot huber at embedded-brains dot de
2010-04-23 09:14 ---
Created an attachment (id=20470)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20470&action=view)
Compile errors from above "$ make -i".
--
http://gcc.gnu.org/bugzill
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot huber at embedded-brains dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43865
--- Comment #1 from sebastian dot huber at embedded-brains dot de
2010-04-23 06:55 ---
Created an attachment (id=20468)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20468&action=view)
Proposed changes.
An alternative is to define this class in a separate file.
--
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot huber at embedded-brains dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43863
--- Comment #1 from sebastian dot huber at embedded-brains dot de
2010-04-22 14:25 ---
Created an attachment (id=20463)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20463&action=view)
Example how to implement it
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852
++
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot huber at embedded-brains dot de
http://gcc.gnu.org
On Mon, Apr 5, 2010 at 22:16, spop at gcc dot gnu dot org
wrote:
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157977
> Log:
> Use build_nonstandard_integer_type.
This commit seems to create problems both in chrec_convert and in the
niter estimations: these use unsigned_type_for and sig
On Mon, Apr 5, 2010 at 04:47, rguenth at gcc dot gnu dot org
wrote:
> You shouldn't be using type_for_size but instead use
> build_nonstandard_integer_type.
I copied this from another LNO pass, should I also update that pass?
What about this patch?
Seb
On Wed, Mar 24, 2010 at 16:35, howarth at nitro dot med dot uc dot edu
wrote:
>> Fixed.
>>
>> Please use ftp://gcc.gnu.org/pub/gcc/infrastructure/cloog-ppl-0.15.9.tar.gz
>>
>
> Shouldn't the required cloog-ppl version in configure be bumped from 0.15.5 to
> 0.15.9?
>
Richi what do you think?
On Sat, Mar 20, 2010 at 05:45, dominiq at lps dot ens dot fr wrote:
> Do you understand why graphite does not detect that the loop for [scat_1+1,
> T_10-2] depends on the one for [0, scat_1-1]?
Graphite does know this, but it does not ask CLooG to generate
[0, scat_1-1] after [scat_1+1, T_10-2],
> Well it could be vectorized even without range splitting. The issue is the
> "sinking" of the store to a[i].
You mean that the problem is the if-conversion of the stores
"a[i] = ..."
On Wed, Feb 10, 2010 at 12:26, amonakov at gcc dot gnu dot org
wrote:
> I don't see how this patch makes simple_iv call from number_of_iterations_exit
> return true for j_20. Could you please kindly explain?
We used to analyze the second scop after the code generation of the
first one. In that
be to rename all the scev info based on the
rename_map that is computed by the translation of the first scop.
I am working on a patch to do that.
Sebastian
> Ok, I have that fixed locally at the place of the patch but I wonder if
> initial_condition () shouldn't return for example
>
> 1ul for (unsigned long) { 1, +, 1 }_1
>
This is correct.
> and
>
> (int) i_2 for (int) { i_2, +, 1 }_1
>
> and further (for short i_2)
>
> i_2 for (short) { (int) {
> htab_hash_pointer is fine if a hash table is never traversed, or such
> traversal
> can't affect code generation. E.g. graphite has some debug_* routines that
> traverse such hash tables, that's fine, they aren't called at all during
> compilation except for debugging sessions.
Ok, thanks for
--- Comment #5 from sebastian dot huber at embedded-brains dot de
2009-12-04 13:31 ---
This one works:
arm-elf-gcc (GCC) 4.4.3 20091201 (prerelease)
I think that r150545 introduced the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41780
--- Comment #3 from sebastian dot huber at embedded-brains dot de
2009-12-04 12:15 ---
The problem is still present with:
arm-elf-gcc (GCC) 4.5.0 20091203 (experimental)
--
sebastian dot huber at embedded-brains dot de changed:
What|Removed
b hard limit on darwin. One
> solution could be to replace 1 with 4000. Also the following patch works.
Please update the size of arrays.
Thanks,
Sebastian
--- Comment #2 from sebastian dot huber at embedded-brains dot de
2009-10-26 10:22 ---
Target: arm-elf
Configured with: /home/sh/gcc-4.5-20091015/configure
--prefix=/opt/tool-chain-elf --target=arm-elf --verbose --with-gnu-as
--with-gnu-ld --enable-languages=c
Thread model: single
gcc
On Fri, Oct 23, 2009 at 14:46, spop at gcc dot gnu dot org
wrote:
> and the code generated by CLooG for the interchange looks like this:
>
> for (scat_1=0;scat_1<=2;scat_1++) {
> for (scat_3=0;scat_3<=2;scat_3++) {
> S4(scat_1,scat_3) ;
> for (scat_5=0;scat_5<=2;scat_5++) {
> S5(scat_1
--- Comment #1 from sebastian dot huber at embedded-brains dot de
2009-10-21 09:30 ---
Created an attachment (id=18852)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18852&action=view)
Fix proposal
This works at least for me.
--
http://gcc.gnu.org/bugzilla/show_bug
ncs.asm" broken for THUMB
version 1 since r150545
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
R
--- Comment #15 from sebastian dot huber at embedded-brains dot de
2009-10-12 11:36 ---
(In reply to comment #13)
> Thanks for clarifying the !eh_personality_libfunc requirement. I'll do some
> experiments to see which solution works best in 4.4.
>
Is the target milesto
Could you run gdb and report the backtrace?
# gdb build-gcc/gcc/cc1
(gdb) run -O3 -floop-strip-mine ... aes.i
(gdb) bt
Thanks,
Sebastian
What changed from 4.4 to 4.5 is that we now get to compile larger
SCoPs with Graphite. In 4.5, Graphite can deal with reductions and
other unhandled constructs like the NE_EXPR that Fortran is frequently
using for representing the exit condition of DO loops.
--- Comment #3 from sebastian dot redl at getdesigned dot at 2009-06-02
18:45 ---
Curiously enough, N2857 doesn't even require that exception_ptr be usable in
conditions. I must have simply assumed that anything with _ptr in its name must
be a valid condition.
So yeah, if the AB
> + /* Increase the limit by the PHI argument number to avoid exponential
> + time and memory complexity. */
This looks good.
Thanks,
Sebastian
--- Comment #1 from sebastian dot huber at embedded-brains dot de
2009-04-16 10:02 ---
Created an attachment (id=17648)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17648&action=view)
Proposal for trunk
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39784
ReportedBy: sebastian dot huber at embedded-brains dot de
GCC build triplet: *
GCC host triplet: *
GCC target triplet: m68k-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39784
--- Comment #9 from sebastian dot wenzler at hp dot com 2009-04-16 06:40
---
I had the same problem with Solaris 10 on sparcv9 with gcc-4.3.3.
Environment:
1) binutils/2.15 2) bison/1.875 3) automake/1.4-p5 4) gcc/4.2.4
LD_RUN_PATH=/local/scratch/xhpsewe/424-64bit/lib
Awesome! Thanks Li, the patch looks good. Tobias will take care
of including it to the graphite branch.
Sebastian
data reference
analysis.
I'm testing the patch on the gcc farm, and will send it to the gcc-patches
once it finishes regstrap.
Sebastian
* graphite.c (exclude_component_ref): Renamed contains_component_ref_p.
(is_simple_operand): Call contains_component_ref_p before calling data
reference ana
Thanks for the reduced testcase, it completely went out of my radar
(by now my delta script should have finished reducing it as well on
the gcc-farm, but I won't even look at it).
Thanks again for the reduced case. I will look at the bug now.
Sebastian
(int) ivtmp.25_2;
# VUSE { SMT.10 SMT.11 }
D.1617_15 = *in_47;
# SMT.10_30 = VDEF
@@ -116,7 +123,7 @@
out_16 = out_48 + 1;
in_17 = in_47 + 1;
i_18 = i_49 + 1;
-if (num_comp_14(D) > i_18)
+if (ivtmp.25_2 < D.1654_4)
Hi,
Can you try this patch. It should fix your problem. I will bootstrap
and test the
patch and send it for review.
Thanks,
Sebastian Pop
--
AMD - GNU Tools
On Thu, Feb 26, 2009 at 13:46, il dot basso dot buffo at gmail dot com
wrote:
>
>
> --- Comment #9 from il dot basso dot
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot schlingmann at web dot de
GCC host triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38935
--- Comment #5 from j dot s dot sebastian at gmail dot com 2009-01-20
15:13 ---
It seems with libstdc++ from svn trunk the bug disappears.
Both
__gnu_parallel::sort(v.begin(), v.end());
and
__gnu_parallel::sort(v.begin(), v.end(),std::less());
now compile and run.
At the
--- Comment #1 from j dot s dot sebastian at gmail dot com 2009-01-19
13:50 ---
After some trial and error, I found it does compile (on same system) if I
modify the code as follows, to use the 3-argument version of sort:
#include
#include
int main()
{
std::vector v(100
ried using none,
-march=i686, and -march=native, with identical results.
This is an up-to-date ubuntu 8.10, by the way.
--
Summary: Parallel mode example code does not compile
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
P
Hi,
Thanks for this report. Please also test with the code of graphite
branch that contains a
patch that schedules several scalar optimizations that can improve the
quality of the code generated.
Thanks,
Sebastian Pop
--
AMD - GNU Tools
aphite.exp that could supply it either.
> Is this the intended behavior or is there something missing in this test (and
> possibly other graphite ones)?
The test for loop blocking is missing in block-3.c. We will have to
clean up the graphite testsuite and making the tests more reliable,
but probably this will be done in GCC4.5.
Sebastian
Attached a fix for this PR. I will regstrap and submit for review.
Sebastian
2009-01-14 Sebastian Pop
PR middle-end/38431
* graphite.c (get_vdef_before_scop, scop_adjust_vphi): New.
(scop_adjust_phis_for_liveouts): Call scop_adjust_vphi.
(gloog): Do not call cleanup_tree_cfg
) output of change_bond_length function, and I suspect
that this is a global variable whose value is needed elsewhere outside
the change_bond_length function.
The bug is in the detection of scalar reductions.
Sebastian
2
Description: Binary data
at you
reported failing:
./cp2k.sopt canonical.inp
CP2K: The specified file canonical.inp can not be opened, it does not exist.
STOP 1
Could you tell me where I can find the canonical.inp file, or how to
reproduce the fail?
Thanks,
Sebastian
t the result.
But this should be fixed now by the patch for PR38559.
Sebastian
--- Comment #17 from sebastian dot redl at getdesigned dot at 2009-01-07
21:14 ---
I have no idea how a prepended member can change the negative offset of the
other struct members. If I did, the bug wouldn't be there.
Is wrapping the struct in another struct the best way to e
nt.cgi?id=16880&action=view)
> Updated patch reviewed by Sebastian
This looks better thanks. Ok for graphite branch.
On Fri, Nov 28, 2008 at 3:38 AM, jakub at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> The patch looks good to me (if not obvious). Sebastian, are you going to post
> it to gcc-patches?
I just sent it to gcc-patches.
Sorry this took me so long to send: it went out of my radar.
Sebastian
Thanks for catching the missing parts.
Here is the updated patch. Does this patch look correct?
I sent this patch to test on the gccfarm and will send an email to
gcc-patches after it completes regstrap.
Thanks,
Sebastian
On Tue, Nov 25, 2008 at 5:08 PM, ghazi at gcc dot gnu dot org
<[EM
ported first: this fails in the
debug dumps function. Could you report the backtrace using the following
flags:
gfortran -O3 -ftree-vectorize -ftree-parallelize-loops=2 -c ma57.f
Thank you,
Sebastian
Here is a patch from Dwarak for fixing this.
He will send this to review on gcc-patches@ list.
Sebastian Pop
--
AMD - GNU Tools
--- Makefile.in 2008-10-23 10:33:51.274495000 -0500
+++ Makefile.in.fix 2008-11-19 16:11:55.80298 -0600
@@ -903,8 +903,9 @@ BUILD_LIBDEPS=3D $(BUILD_LIBIBERTY
The patch looks good. Please test and ask for approval to
commit to trunk on [EMAIL PROTECTED]
Thanks,
Sebastian
1 - 100 of 182 matches
Mail list logo
