https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49743
--- Comment #5 from Gary Funck ---
(In reply to Eric Gallager from comment #4)
> Any plans to resubmit the GUPC branch again?
Eric, no not at this time. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71872
--- Comment #10 from Gary Funck ---
Thanks. Works for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71872
--- Comment #1 from Gary Funck ---
(In reply to Gary Funck from comment #0)
> See also PR 70683.
>
> When the attached test case is compiled with -O3 and gcc checks are enabled,
> the following ICE is triggered.
>
> It looks like this check was
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: gary at intrepid dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71787
--- Comment #2 from Gary Funck ---
Manuel, thanks for the quick follow up.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gary at intrepid dot com
Target Milestone: ---
This bug may be related to PR41517.
Consider the following program:
#define NULL ((void *)0)
typedef enum {GET, SET} op_t;
extern void abort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69123
Gary Funck changed:
What|Removed |Added
CC||gary at intrepid dot com
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69026
--- Comment #1 from Gary Funck ---
This can be most easily reproduced by doing a regular configure and make, then
cd-ing into the gcc build directory and forcing a re-compilation of dwarf2out.c
at -O3.
cd bld/gcc
rm dwarf2out.o
make CXXFLAGS='-O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69025
--- Comment #1 from Gary Funck ---
This can be most easily reproduced by doing a regular configure and make, then
cd-ing into the gcc build directory and forcing a re-compilation of df-scan.c
at -O3.
cd bld/gcc
rm df-scan.o
make CXXFLAGS='-O3 -g
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gary at intrepid dot com
Target Milestone: ---
While trying to build and bootstrap GCC at -O3 (using
--with-build-config=bootstrap-O3) on an x86-64, the compiler hangs in the final
stage while trying to build
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: gary at intrepid dot com
Target Milestone: ---
This showed up as a bootstrap failure when CFLAGS='-O3' becaus
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: gary at intrepid dot com
Target Milestone: ---
This showed up as bootstrap failure when building with CFLAGS='-O3', because
when the stage2 compiler is compiled at -O3 usin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117
--- Comment #38 from Gary Funck ---
(In reply to Richard Biener from comment #37)
>
> Does the following help on r230428 or newer?
>
> Index: gcc/tree-ssa.c
> ===
> --- gcc/tree-ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117
--- Comment #36 from Gary Funck ---
(In reply to rguent...@suse.de from comment #35)
> Yes, I thought the cfgexpand.c place is a better one and the only one
> that would be related to the place where I removed the old
> redirect_edge_var_map_dest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117
--- Comment #34 from Gary Funck ---
(In reply to Richard Biener from comment #33)
> Can you try the patch attached to comment #29?
That seemed to fix the issue in 32/libgfortran, though I haven't tried a build
from scratch yet.
Regarding the pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117
--- Comment #32 from Gary Funck ---
(In reply to Gary Funck from comment #17)
> We're seeing this ICE on x86-64, while building the 32-bit libgfortran.
> We're building the target libraries with -O3 with GCC compiler checks
> enabled.
The recent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68269
Gary Funck changed:
What|Removed |Added
CC||gary at intrepid dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117
--- Comment #19 from Gary Funck ---
We see similar failure an x86-64 opensuse VM in the 32-bit libgfortran build
but on a different file: eoshift.c. After removing the .lo and .o files and
re-running make, the build completed without error. As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117
--- Comment #18 from Gary Funck ---
(In reply to Gary Funck from comment #17)
> We're seeing this ICE on x86-64, while building the 32-bit libgfortran.
> We're building the target libraries with -O3 with GCC compiler checks
> enabled.
Taking gar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117
--- Comment #17 from Gary Funck ---
We're seeing this ICE on x86-64, while building the 32-bit libgfortran.
We're building the target libraries with -O3 with GCC compiler checks enabled.
libtool: compile: /eng/upc/dev/gary/gupc-dev/bld/gupc/./g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67792
--- Comment #2 from Gary Funck ---
(In reply to Andreas Schwab from comment #1)
> Nobody is testing make clean, patches welcome. It's much easier to just
> remove the build directory before starting over.
OK. I don't plan on looking into it.
Assignee: unassigned at gcc dot gnu.org
Reporter: gary at intrepid dot com
Target Milestone: ---
When building with both the GCC 5.2 release and the latest gcc-5-branch, after
a successful build and bootstrap, a 'make clean' at the top level fails as
follows.
make[1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67341
--- Comment #3 from Gary Funck ---
(In reply to Marek Polacek from comment #2)
> Gary, could you please try this again? I'd hope this has really been fixed
> with my recentish Go patch.
Confirmed - fixed.
: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: gary at intrepid dot com
Target Milestone: ---
A change made to the trunk within the past week/so (trunk version greater than
227110
: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: gary at intrepid dot com
CC: cmang at google dot com
Target Milestone: ---
For a full bootstrap build, we also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164
--- Comment #49 from Gary Funck ---
(In reply to Alexandre Oliva from comment #48)
> The errors reported in comments 44, 45, 46, and 47 are fixed in the git
> branch aoliva/pr64164. I'm giving it all some more testing before posting
> an updated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67000
--- Comment #4 from Gary Funck ---
(In reply to Alexandre Oliva from comment #3)
> The problem initially reported in this bug is now fixed in the git branch
> aoliva/pr64164. I'm not sure how to go about duplicating the one in comment
> 1, but,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67045
Gary Funck changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67045
Gary Funck changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67045
--- Comment #1 from Gary Funck ---
Additional info, this failed when trying to build the stage 2 target libgcc.
make[3]: Leaving directory '/home/gfunck/gcc-trunk/bld/powerpc64le-unknown-linu
x-gnu/libgcc'
Makefile:15864: recipe for target 'all-
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gary at intrepid dot com
Target Milestone: ---
This issue may be related to bug #61047; it refers to a fix made on July 1, and
the regression described below
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66984
--- Comment #7 from Gary Funck ---
Don't know what the criteria is for closing bugs, but as far as I'm concerned,
this bug can be marked resolved and the other two referenced PR's marked as
duplicates of this one. (They're against older rev's, s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67009
--- Comment #4 from Gary Funck ---
(In reply to Mikhail Maltsev from comment #3)
> Confirmed, I also see it in my builds since 20.07 (several cases of
> -Wshift-overflow were implemented in r225998).
>
> (In reply to Andrew Pinski from comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67000
--- Comment #1 from Gary Funck ---
We're seeing this as a bootstrap failure in libitm, built with checks enabled
and both host and target compilation flags set to -O0. We do not see the ICE
when compiled at -O3 and --enable-checking=release. Th
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: gary at intrepid dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66984
--- Comment #5 from Gary Funck ---
(In reply to Jay from comment #2)
> 2 I suggest that gcc's C/C++ frontends expose these other forms of division,
> for the sake of testability.
Perhaps defining a builtin for CEIL_DIV_EXPR and FLOOR_DIV_EXPR mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66984
--- Comment #4 from Gary Funck ---
(In reply to Jay from comment #2)
> 1 please be sure that dividing the most negative number by -1 "works".
> Perhaps just don't optimize anything with negstive numbers.
- Checking for negative numbers at compi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66984
--- Comment #3 from Gary Funck ---
(In reply to Richard Biener from comment #1)
> The usual fix in fold-const.c is to make sure to convert operands to the
> required type when building the final expression. Thus instead of
>
> 10828 r
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: gary at intrepid dot com
Target Milestone: ---
This problem was previously reported in bug #46679 and bug #56363. I'm logging
it as new issue becau
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66181
--- Comment #14 from Gary Funck ---
*** Bug 66283 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66283
Gary Funck changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66283
--- Comment #1 from Gary Funck ---
FYI, this also results in a bootstrap failure for C++ on IA64, when configured
with:
CFLAGS='-g3 -O0' \
CXXFLAGS='-g3 -O0' \
$src/configure \
--prefix=$rls \
--enable-checking \
--enable-languages=c,c++
: major
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gary at intrepid dot com
Target Milestone: ---
This recent commit implemented additional type verification checks:
r223252 | hubicka | 2015-05-16 13:51:50 -0700 (Sat, 16 May
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62198
--- Comment #4 from Gary Funck ---
I realize that this bug has been closed as invalid, thus making the warning
valid.
However, if the warning is valid what can be done to this declaration to avoid
the warning?
const int (*X0)[10] = alloc (10
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gary at intrepid dot com
Although this bug is filed against the 5.0 trunk, it can be duplicated with at
least 4.8.3.
Given:
$ cat q.c
typedef unsigned long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61679
--- Comment #7 from Gary Funck ---
(In reply to Trevor Saunders from comment #6)
> thanks! I think the attached patch should fix all of those issues, would
> you mind testing it?
Confirmed. With that patch, the stage1 compiler compiled successf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61679
--- Comment #5 from Gary Funck ---
(In reply to Trevor Saunders from comment #3)
> Is the below list complete? I'd expect to see
> errors for the partial specialization for true as well.
Attached the full make log.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61679
--- Comment #4 from Gary Funck ---
Created attachment 33076
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33076&action=edit
make log after trying patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61679
--- Comment #2 from Gary Funck ---
(In reply to Trevor Saunders from comment #1)
> The following patch compiles with 4.9 for me, but I don't have easy
> access to a machine with 4.5 on it, would you mind testing if it works
> for you?
Applied th
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: gary at intrepid dot com
This build failure shows up on a recent source version of GCC 4.10 (212138
2014-06-30). An attempt to bootstrap the compiler on an older
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60439
--- Comment #12 from Gary Funck ---
I submitted Bug #61480 documenting the interaction between Var() and Init().
The test case that I posted is abstracted from actual code. As far as which
switches should be default and/or enabled by -Wall, tha
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: gary at intrepid dot com
CC: jsm28 at gcc dot gnu.org, nenad at intrepid dot com
While researching an issue related to Bug 60439, I notice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60439
--- Comment #10 from Gary Funck ---
The following test case when compiled against a recent trunk revision (211365
2014-06-08) generates a warning, as intended by the patch described in comment
8.
int a, x;
int
main ()
{
switch (!x)
{
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gary at intrepid dot com
CC: nenad at intrepid dot com
Target: x86_64
Created attachment 32880
--> ht
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60790
Gary Funck changed:
What|Removed |Added
Attachment #32569|0 |1
is obsolete|
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: gary at intrepid dot com
CC: nenad at intrepid dot com, PHHargrove at lbl dot gov,
rth at gcc dot gnu.org
Created attachment 32569
--> h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58572
--- Comment #1 from Gary Funck ---
We're seeing a similar failure on SUSE SLE 11.2. The installed version of gcc
is 4.3.4.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566
--- Comment #12 from Gary Funck 2012-12-03 17:24:03
UTC ---
(In reply to comment #10)
> Thanks for the experiment. I think that you just need to always bootstrap the
> compiler (i.e. don't pass --disable-bootstrap) since it's precisely de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566
--- Comment #9 from Gary Funck 2012-12-03 02:02:18
UTC ---
(In reply to comment #3)
> I will try building svn revision 152973 on an x86-64 box, and see if the
> problem can be reproduced there.
I built fully bootstrapped the gcc/g++ com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566
--- Comment #7 from Gary Funck 2012-12-02 21:49:49
UTC ---
(In reply to comment #4)
> The compiler bootstraps fine for me btw.
Which version of the host compiler did you use to run the initial build step?
Which OS and target architectu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566
--- Comment #6 from Gary Funck 2012-12-02 21:48:28
UTC ---
"This isn't a bootstrap since you pass --disable-bootstrap to configure ..."
Agreed. I didnt' know how to classify this problem.
Since the version of 4.7.0 that I used appears
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566
--- Comment #5 from Gary Funck 2012-12-02 21:45:52
UTC ---
Cancel the previous comment regarding the idea that this might be related to
using the system installed gcc. The build failed while trying to build gmp,
and hadn't gotten to tryin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566
--- Comment #3 from Gary Funck 2012-12-02 21:32:14
UTC ---
This failure may be related to the use of the installed gcc compiler (gcc (SUSE
Linux) 4.3.4 [gcc-4_3-branch revision 152973]). I tried a gcc 4.7.0 compiler
that we built circa Fe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566
--- Comment #2 from Gary Funck 2012-12-02 20:43:45
UTC ---
The configure options specified are:
CC=/usr/bin/gcc
CXX=/usr/bin/g++
$src/configure --enable-languages=c,c++
--enable-checking --disable-bootstrap --disable-multilib
--disab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566
--- Comment #1 from Gary Funck 2012-12-02 20:32:03
UTC ---
Created attachment 28855
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28855
build failure Ia64 segv - continues to fail in r194044 (in libgcc config. test)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566
Bug #: 55566
Summary: [4.8 regression] [IA64] ICE during bootstrap (related
to recent "vec" re-implementation?)
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158
--- Comment #10 from Gary Funck 2012-12-01 23:17:00
UTC ---
(In reply to comment #9)
> OK, I applied it to our autotester and we will see tomorrow if it fixes the
> segfaults.
> If so, can I go ahead and commit it?
>
> Honza
Ping: w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158
--- Comment #8 from Gary Funck 2012-11-09 15:26:46
UTC ---
(In reply to comment #5)
> Completely untested patch for someone else to foster-parent:
> + }
> + }
> f = find_fallthru_edge (last_bb->succs);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158
--- Comment #2 from Gary Funck 2012-11-01 00:35:41
UTC ---
I tried making the change suggested in the previous comment and ran into a
segfault here:
5876dump_new_block_header (0, *target_bb, head, tail);
5877
5878 if (init
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158
--- Comment #1 from Gary Funck 2012-11-01 00:15:54
UTC ---
Some additional debugging information.
In sched_rgn_init(), the bb_state array is initialized.
3049{
3050 bb_state_array = (char *) xmalloc (last_basic_block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158
Bug #: 55158
Summary: ICE: [4.8 Regreesion] [IA64] segv in schedule_region
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49743
--- Comment #3 from Gary Funck 2012-08-28 02:20:38
UTC ---
Recently, I've been reviewing changes that we made on the GUPC branch (see
comment #2) that are candidates for the trunk revision (or in this case,
possibly the 4.7 branch).
Index: gcc/c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54326
--- Comment #1 from Gary Funck 2012-08-19 20:54:51
UTC ---
Don't know if this is relevant, but a recent thread on the clang-dev list
explored the differences between GCC and clang in the handling of const and
constexpr.
"clang vs GCC error case:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54326
Bug #: 54326
Summary: GCC does not build with G++ version 3.4.0
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54324
Bug #: 54324
Summary: GCC install document does not list minimum required
g++ versions
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54308
--- Comment #5 from Gary Funck 2012-08-18 18:39:42
UTC ---
(In reply to comment #1)
> (Note, apparent s/4.2.1/4.1.2/g in initial description.)
>
> I'd suggest updating to just a later gcc build, if you can find *only slightly
> newer* rpm:s; as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54279
Bug #: 54279
Summary: first stage build with g++ fails with "." as the first
component of $PATH
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #44 from Gary Funck 2012-08-15 14:45:42
UTC ---
(In reply to comment #43)
> The problem is we return a TI union in XF register
> because the x86-64 psABI.
Is this the same problem documented in comment #9?
The patch that you suggest
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #41 from Gary Funck 2012-08-15 13:47:37
UTC ---
(In reply to comment #38)
> What are the code generation deficiencies you are targeting with this? For
> testcase #1 I get
>
> sptr_result:
> .LFB0:
> .cfi_startproc
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #37 from Gary Funck 2012-08-15 03:34:55
UTC ---
(In reply to comment #36)
> (In reply to comment #35)
> > Note that for the test case in comment #34 (and comment #9) to fail that the
> > MAX_FIXED_MODE_SIZE patch has to be applied, an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #35 from Gary Funck 2012-08-15 00:00:43
UTC ---
Note that for the test case in comment #34 (and comment #9) to fail that the
MAX_FIXED_MODE_SIZE patch has to be applied, and likely GCC internal checking
has to be enabled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #34 from Gary Funck 2012-08-14 23:55:57
UTC ---
(In reply to comment #33)
> We must make sure that
>
> ---
> union S160
> {
> long double a;
> };
> extern union S160 check160 (void);
> extern void checkx160 (union S160);
> void
> t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142
--- Comment #15 from Gary Funck 2012-08-14 13:17:26
UTC ---
(In reply to comment #14)
> Yeah, IMHO it should have added
> %{!mpower*: %(asm_default)}} \
> line instead of
> %{!mpowerpc*: -mcom}} \
That change fixed the build failure on a POW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #30 from Gary Funck 2012-08-14 04:24:54
UTC ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00839.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142
--- Comment #11 from Gary Funck 2012-08-13 23:00:57
UTC ---
It is possible that revision 189908 introduced the 'mcom' change.
Index: src/gcc/config/rs6000/rs6000.h
===
--- src/gcc/c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #28 from Gary Funck 2012-08-12 22:43:16
UTC ---
(In reply to comment #27)
> Please try this patch:
>
> diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
> index c4d85b7..6c4c2ce 100644
> --- a/gcc/config/i386/i386.h
> +++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #26 from Gary Funck 2012-08-12 22:14:56
UTC ---
Typo fixed below:
#define MAX_FIXED_MODE_SIZE targetm.scalar_mode_supported_p (TImode) ? TImode :
DImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #25 from Gary Funck 2012-08-12 22:08:50
UTC ---
(In reply to comment #20)
> X86 doesn't support __int128 and requires SSE for TImode.
> We may need to limit those testcases for int128 target.
If targeting struct's to TImode is suppor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
Gary Funck changed:
What|Removed |Added
Attachment #27997|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
Gary Funck changed:
What|Removed |Added
Attachment #27996|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
Gary Funck changed:
What|Removed |Added
Attachment #27995|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #21 from Gary Funck 2012-08-12 21:24:40
UTC ---
(In reply to comment #20)
> X86 doesn't support __int128 and requires SSE for TImode.
> We may need to limit those testcases for int128 target.
OK, I'll add: /* { dg-require-effective-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #19 from Gary Funck 2012-08-12 18:30:25
UTC ---
(In reply to comment #15)
> Do we have a run-time testcase?
I attached three compile-time test cases that check if the generated RTL refers
to TImode values. The test cases are set up
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #18 from Gary Funck 2012-08-12 18:17:19
UTC ---
Created attachment 27997
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27997
test case #3 - struct targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #17 from Gary Funck 2012-08-12 18:11:25
UTC ---
Created attachment 27996
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27996
test case #2 - struct targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #16 from Gary Funck 2012-08-12 18:08:05
UTC ---
Created attachment 27995
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27995
test case #1 - struct targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #14 from Gary Funck 2012-08-11 03:22:34
UTC ---
(In reply to comment #13)
> Is this bug obsolete now?
Comment #7 (2005-06-25) states that this is a valid bug, and near as I can tell
the current compiler still does not target 16-byte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142
--- Comment #7 from Gary Funck 2012-08-11 01:24:37
UTC ---
We're still running into this build failure on PPC64, using a recent revision
of the HEAD version. Is there additional information that is needed to help
track down the cause of the buil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142
--- Comment #5 from Gary Funck 2012-07-31 17:14:24
UTC ---
Here is the complete output at the point of a make failure.
/home/garyf/gcc-4.8/wrk/./gcc/xgcc -B/home/garyf/gcc-4.8/wrk/./gcc/ -B/home/gar
yf/gcc-4.8/rls/powerpc64-unknown-linux-gnu/bin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142
--- Comment #4 from Gary Funck 2012-07-31 16:57:55
UTC ---
One of target platforms is running RHEL 6.2 on a POWER7 series processor.
The binutils RPM is:
binutils-2.20.51.0.2-5.28.el6.ppc64
1 - 100 of 199 matches
Mail list logo
