mmary: create_tmp_var_raw (gimplify.c) inadventently asserts
'volatile' on temps
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at g
--- Comment #2 from gary at intrepid dot com 2006-05-05 16:06 ---
Created an attachment (id=11382)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11382&action=view)
create_tmp_var_raw patch: remove type qualifiers
This patch compiles, but hasn't been tested.
--- Comment #3 from gary at intrepid dot com 2006-05-05 16:12 ---
(In reply to comment #1)
> Do you have a testcase this will better understand the problem and to see if
> your patch is correct?
I'm not sure how to demonstrate that there is a problem. I think it
is cle
--- Comment #5 from gary at intrepid dot com 2006-05-05 16:37 ---
(In reply to comment #4)
> Then the real question is why do you think this is a bug?
1. it is a bug to create temporaries and assert 'volatile' on them
2. there is code in create_tmp_var_raw() that create
--- Comment #7 from gary at intrepid dot com 2006-05-05 16:58 ---
Consider the following:
volatile int j;
void p()
{
++j;
}
Gimplify in its present form might transform the statement above into
something like the following:
volatile int j;
void p()
{
volatile int T1;
T1 = j + 1
--- Comment #9 from gary at intrepid dot com 2006-05-05 17:55 ---
> Your issue with ++j not using incr is not related to the gimplifier at all as
> it also happens in every compiler version since at least 2.95.3.
I agree that is unrelated. I didn't file this bug thinking th
--- Comment #12 from gary at intrepid dot com 2006-05-06 01:42 ---
Given the above, I suggest that my bug report be marked closed,
because the problem I was seeing in 4.0.1 is fixed by the
change to create_tmp_from_val that passes in TYPE_MAIN_VARIANT().
Note that the use of the main
gcc dot gnu dot org
ReportedBy: gary at intrepid dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28141
--- Comment #2 from gary at intrepid dot com 2006-06-23 16:44 ---
I agree this is definitely an enhancement, but will note the following:
1. On Fedora Core 5, x86_64, I was able to successfully link and run
a null program (written in assembly) that initializes thread local
'ptr&
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gary at intrepid dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Additional Comments From gary at intrepid dot com 2005-02-17 19:35
---
The MAX_FIXED_REC_SIZE defintion is a relatively recent addition to
config/rs6000.h (and from a quick review of the cvs log, it seems that this
change hasn't yet been incorporated into a release.) Jus
--- Additional Comments From gary at intrepid dot com 2005-02-17 21:41
---
> Also note MAX_FIXED_MODE_SIZE was changed on
> rs6000 for a reason and not for an optimization issue.
Based on my interpretaion of the procedure call ABI, both this problem and a
related Bug
--- Additional Comments From gary at intrepid dot com 2005-02-17 22:39
---
> I think that Bug #19566 is a real bug. The ABI specifies to pass 16byte
> structs in registers. Anyway MAX_FIXED_MODE_SIZE doesn't influence
> the calling convention ...
Thanks for the
ersion: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gary at intrepid dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20319
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gary at intrepid dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20321
--- Additional Comments From gary at intrepid dot com 2005-03-04 20:24
---
"Emit variables declared @code{static const} when optimization isn't turned
on, even if the variables aren't referenced."
How odd. I should've checked the docs, but this brief explanat
--- Additional Comments From gary at intrepid dot com 2005-03-04 21:54
---
Here is some detail on my proposed change in behavior:
1) Change the default setting to -fno-keep-static-consts:
/* Nonzero means that we should emit static const variables
regardless of whether or not
Severity: minor
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gary at intrepid dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20533
--- Additional Comments From gary at intrepid dot com 2005-03-18 16:16
---
from http://gcc.gnu.org/ml/gcc/2005-03/msg00491.html
I think that the switch name
-fkeep-static-consts might be more consistenly named if it
was given the opposite sense and named something like
-fdelete-unused
--- Comment #9 from gary at intrepid dot com 2008-09-27 00:18 ---
(In reply to comment #8)
> It has been fixed in gcc 4.1.2.
FWIW, I just tried this on a gcc 4.0.1 that we have on hand here, and it also
appeared to be fixed in that version.
--
http://gcc.gnu.org/bugzi
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=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=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 #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 #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 #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 #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
Gary Funck changed:
What|Removed |Added
Attachment #27995|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 #27997|0 |1
is obsolete|
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
--- 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 #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=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 #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 #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 #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=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 #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 #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 #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=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=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=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=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=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=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=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=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
--- 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 #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=50010
--- Comment #4 from Gary Funck 2011-08-20 17:03:58
UTC ---
We ran a reghunt of sorts and came up with the following results.
The first confirmed bootstrap comparison failure occurred after
revision 177265 was applied.
r177265 | uros | 2011-08-0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50010
--- Comment #6 from Gary Funck 2011-08-20 19:35:11
UTC ---
(In reply to comment #2)
> (In reply to comment #0)
> > x86_64-unknown-freebsd seems to work, and with nobody seeing this on
> > GNU/Linux
> > I am wondering whether this may be due to i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50010
--- Comment #7 from Gary Funck 2011-08-20 20:52:08
UTC ---
(In reply to comment #6)
> On FC14 x86_64, after installing the i686 libraries for
> {gmp,libmpc,mpfr}{,-devel}, built against trunk
> revision 177922 (last changed 2011-08-19 17:18:07 PD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50010
--- Comment #12 from Gary Funck 2011-09-11 16:29:39
UTC ---
(In reply to comment #10)
> Putting binutils 2.21.1 in PATH before the system versions of these tools,
> which are binutils 2.17.50 based, avoids the issue on FreeBSD 9/i386.
On the i68
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50010
--- Comment #16 from Gary Funck 2011-09-12 18:39:20
UTC ---
(In reply to comment #14)
> Created attachment 25246 [details]
> gcc47-pr50010.patch
Bootstraps on i686 CentOS release 5.6 with installed packages.
Jakub, thanks for tracking this down
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50489
Bug #: 50489
Summary: [UPC/IA64] mis-schedule of MEM ref with
-ftree-vectorize and -fschedule-insns2
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50489
--- Comment #1 from Gary Funck 2011-09-22 19:21:54
UTC ---
Created attachment 25343
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25343
UPC test case that demonstrates instruction mis-schedule
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50489
--- Comment #2 from Gary Funck 2011-09-22 19:31:04
UTC ---
Created attachment 25344
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25344
zipped tar file with build script, readme, test case and test artifacts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50489
--- Comment #4 from Gary Funck 2011-09-23 17:38:18
UTC ---
(In reply to comment #3)
> Does the problem vanish if you add -fno-strict-aliasing?
>
> One more thing, you mention -O2 in the flags, but then refer to selective
> scheduler, which is on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50489
--- Comment #6 from Gary Funck 2011-09-25 19:58:58
UTC ---
(In reply to comment #5)
> D.3059_11 = VIEW_CONVERT_EXPR(D.3058);
>
> looks like bogus IL to me. You view D.3058, a struct of size 16, as
> a pointer (of size 8). I suppose you want
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50489
--- Comment #7 from Gary Funck 2011-10-17 03:04:08
UTC ---
Do you have any suggestions on additional tests, debug steps that we can
perform to narrow down the factors that lead to instructions being
mis-scheduled?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53185
Bug #: 53185
Summary: segmentation fault in vectorizable_load
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53185
--- Comment #1 from Gary Funck 2012-05-02 06:11:21
UTC ---
Created attachment 27281
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27281
pre-processed source that demonstrates compiler segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53185
--- Comment #5 from Gary Funck 2012-05-08 16:01:50
UTC ---
Ping. Is there an ETA for a fix for this bug? It is preventing us from being
able to merge from the GCC trunk. Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53185
--- Comment #8 from Gary Funck 2012-05-09 21:43:28
UTC ---
(In reply to comment #7)
> Fixed.
Confirmed. We're able to rebuild our app. without encountering the
segmentation fault.
Thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53390
Bug #: 53390
Summary: ICE: tree check: expected integer_cst, have nop_expr
in vect_compute_data_ref_alignmen on 32-bit x86 host
Classification: Unclassified
Product: gcc
Version:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53390
--- Comment #1 from Gary Funck 2012-05-17 17:12:49
UTC ---
Created attachment 27428
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27428
Test case to demonstrate ICE in tree check on 32-bit host
Test case attached. Compile with "-fpreproce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53390
--- Comment #2 from Gary Funck 2012-05-17 17:25:23
UTC ---
The following versions of the support packages were installed via RPM.
mpfr-devel-2.4.1-6.el6.i686
gmp-devel-4.3.1-7.el6.i686
libmpc-devel-0.8-3.el6.i686
binutils-2.20.51.0.2-5.28.el6.i6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419
Bug #: 53419
Summary: loop incorrectly optimized to endless loop at -O2 for
table delimited by extern addresses (x86-32)
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419
--- Comment #1 from Gary Funck 2012-05-19 19:41:25
UTC ---
Created attachment 27442
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27442
test case demonstrating endless loop at -O2 on x86-32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419
--- Comment #2 from Gary Funck 2012-05-19 19:42:47
UTC ---
Created attachment 27443
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27443
correct code generated at -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419
--- Comment #3 from Gary Funck 2012-05-19 19:43:25
UTC ---
Created attachment 27444
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27444
endless loop generated at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419
--- Comment #6 from Gary Funck 2012-05-19 22:08:26
UTC ---
(In reply to comment #5)
> > extern func_ptr_t init_array_begin[1];
> > extern func_ptr_t init_array_end[1];
>
> The array sizes say they are size of one. If you want to be correct and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419
--- Comment #7 from Gary Funck 2012-05-19 22:11:42
UTC ---
(In reply to comment #4)
> Do you have a self-contained run-time testcase?
I wasn't able to create a run-time tester easily, because the code above relies
upon external labels that are i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53832
Gary Funck changed:
What|Removed |Added
CC||gary at intrepid dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52983
Gary Funck changed:
What|Removed |Added
CC||gary at intrepid dot com
--- Comment #11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142
Bug #: 54142
Summary: ppc64 build failure - Unrecognized opcode: `sldi' (and
`srdi`)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142
--- Comment #1 from Gary Funck 2012-07-31 16:12:18
UTC ---
We have determined that we can bypass the failure with the following configure
switches:
--with-long-double-128 --with-cpu-32=power4 --with-tune-32=power6
--with-cpu-64=power4 --with-tu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142
--- Comment #3 from Gary Funck 2012-07-31 16:53:52
UTC ---
(In reply to comment #2)
> sldi and srdi are both standard PowerPC64 instructions.
>
> How did you configure GCC?
No special switches. For example,
$src/configure \
CFLAGS='-O0 -g3'
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
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=44776
--- Comment #15 from Gary Funck 2012-02-08 07:14:29
UTC ---
We're seeing a similar failure under openSUSE 12.1 running as a VM, which may
have a somewhat constrained memory environment.
*** glibc detected ***
/home/abuild/rpmbuild/BUILD/[...]/gc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44776
--- Comment #16 from Gary Funck 2012-02-08 07:23:31
UTC ---
(In reply to comment #15)
> We're seeing a similar failure under openSUSE 12.1 running as a VM, which may
> have a somewhat constrained memory environment.
We built with trunk version 1
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=51072
--- Comment #7 from Gary Funck 2011-11-21 02:53:42
UTC ---
(In reply to comment #6)
> On Thu, 10 Nov 2011, rguenth at gcc dot gnu.org wrote:
>
> > Shouldn't libitm be built with the "stage1" g++ as it is a target library,
> > even with --disable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33919
--- Comment #5 from Gary Funck 2011-12-22 04:03:55
UTC ---
(In reply to comment #4)
> I'm having this problem too, and it's still happening with GCC 4.5. The ml
> message suggests that this may be hard to fix, but it looks surprisingly easy:
> in
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.
MED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gary at intrepid dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24539
MED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gary at intrepid dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24540
--- Comment #1 from gary at intrepid dot com 2005-10-26 14:39 ---
*** This bug has been marked as a duplicate of 24539 ***
--
gary at intrepid dot com changed:
What|Removed |Added
--- Comment #1 from gary at intrepid dot com 2005-10-26 14:39 ---
*** Bug 24540 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24539
--- Comment #3 from gary at intrepid dot com 2005-10-26 16:07 ---
All/most GCC-supplied dialects may support unit-at-a-time, however,
the dialect we're working on (UPC) does not at present support
unit-at-a-time.
For now, we're de-asserting flag_unit_at_a_time in the languag
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=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=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
--- 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 #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 #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 #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
1 - 100 of 199 matches
Mail list logo
