https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #26 from Paul H. Hargrove PHHargrove at lbl dot gov ---
(In reply to Yury Gribov from comment #25)
Can we close this?
Just tried to build the released 4.8.3 and still see the original problem (see
error messages below). Same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62198
--- Comment #2 from Paul H. Hargrove PHHargrove at lbl dot gov ---
Both icc (v13.0.1) and pgcc (v12.9-0) agree with gcc (and thus disagree with
clang) on this:
$ cat -n q.c
1
2 typedef unsigned long size_t;
3 extern const void
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #21 from Paul H. Hargrove PHHargrove at lbl dot gov ---
A build from svn trunk (r207062) completed w/o problems.
I see:
Configuring in i686-pc-linux-gnu/libsanitizer
followed later by
checking for necessary platform features
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #20 from Paul H. Hargrove PHHargrove at lbl dot gov ---
(In reply to Yury Gribov from comment #19)
Paul, could you check if libsanitizer is now auto-disabled on your system
and close the bug in that case?
Probably can't get
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58996
--- Comment #12 from Paul H. Hargrove PHHargrove at lbl dot gov ---
Balaji,
Reading the patch it looks sufficient.
I will test when I have a chance, but cannot guess how soon that may be,
-Paul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58996
--- Comment #8 from Paul H. Hargrove PHHargrove at lbl dot gov ---
(In reply to Barry Tannenbaum from comment #6)
I don't understand the reluctance to check the defintion of
__cpu_set_t_defined, since it's defined right there in
/usr/include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58996
--- Comment #5 from Paul H. Hargrove PHHargrove at lbl dot gov ---
The patch in comment #2 allows the build to complete without the need to
--disable-libcilkrts. However, I agree with Jakub (comment #3) that use of a
glibc internal macros
: other
Assignee: unassigned at gcc dot gnu.org
Reporter: PHHargrove at lbl dot gov
I have an ancient x86 system running Red Hat 8.
This system's version of Linux and/or glibc lacks definitions of cpu_set_t and
CPU_SETSIZE:
$ grep -rl -e CPU_SETSIZE -e cpu_set_t /usr/include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43027
--- Comment #4 from Paul H. Hargrove PHHargrove at lbl dot gov ---
For what it's worth, the sample input is fine with
gcc-3.2.2
gcc-3.3.3
gcc-3.4.0
gcc-4.0.0
gcc-4.1.0
gcc-4.2.1
gcc-4.3.2
and broken with
gcc-4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #3 from Paul H. Hargrove PHHargrove at lbl dot gov ---
(In reply to Kostya Serebryany from comment #1)
Sorry for the breakages, but we are unable to monitor build failures on old
kernels unless someone sets up a regular testing
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: PHHargrove at lbl dot gov
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
On the same system where I reported bug 55989, I am
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55989
Bug #: 55989
Summary: [4.8 regresion] build failure in libsanitizer
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55989
--- Comment #2 from Paul H. Hargrove PHHargrove at lbl dot gov 2013-01-15
08:59:42 UTC ---
(In reply to comment #1)
Will the following patch work?
[...]
Yes, it allows the compilation to complete.
SInce I don't know anything
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55433
--- Comment #3 from Paul H. Hargrove PHHargrove at lbl dot gov 2013-01-15
09:15:44 UTC ---
This bug is still present and biting me as of r195176.
Is there anything I can do to help make some progress on this?
-Paul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55433
Bug #: 55433
Summary: [4.8 Regression] ICE on excessive reloads
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55433
--- Comment #1 from Paul H. Hargrove PHHargrove at lbl dot gov 2012-11-21
22:48:05 UTC ---
Minor correction:
The line or error output in the Description that reads
testcase.c:10:1: internal compiler error: [...]
should instead read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54326
--- Comment #4 from Paul H. Hargrove PHHargrove at lbl dot gov 2012-08-20
08:22:18 UTC ---
(In reply to comment #3)
Fixed(?).
YES. I was the one to originally observe the failure.
Just svn-uped to revision 190524 and was able to build stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54308
--- Comment #8 from Paul H. Hargrove PHHargrove at lbl dot gov 2012-08-20
08:57:29 UTC ---
(In reply to comment #7)
[...]
Ok, but see comment 4; try just removing the inline there. If necessary,
the
inline can be wrapped in some #ifdef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54308
--- Comment #6 from Paul H. Hargrove PHHargrove at lbl dot gov 2012-08-18
19:05:19 UTC ---
(In reply to comment #5 by Gary Funck)
[...]
FYI, the failing system has Redhat Release 8 (circa 2002). Fedocra Core 8
didn't come out until circa 2007
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54308
Bug #: 54308
Summary: build regression in 190498 on ppc64/linux:
legitimate_indirect_address_p undefined
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54308
--- Comment #2 from Paul H. Hargrove PHHargrove at lbl dot gov 2012-08-18
02:38:21 UTC ---
(In reply to comment #1)
(Note, apparent s/4.2.1/4.1.2/g in initial description.)
Correct, I am sorry about that.
I'd suggest updating to just a later
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54308
--- Comment #3 from Paul H. Hargrove PHHargrove at lbl dot gov 2012-08-18
03:02:36 UTC ---
(In reply to comment #1)
I'd suggest updating to just a later gcc build, if you can find *only slightly
newer* rpm:s; as for a x86_64-linux F 8 with gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142
--- Comment #8 from Paul H. Hargrove PHHargrove at lbl dot gov 2012-08-13
22:04:40 UTC ---
The following is a transcript of a test I just tried one of my systems where
Gary and I have observed this bug. The test appears to show that the gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142
--- Comment #9 from Paul H. Hargrove PHHargrove at lbl dot gov 2012-08-13
22:42:16 UTC ---
Following up on my previous experiment, I tried the same input with the xgcc
which is failing to build libdecnumber. If also fails with the 1-line test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142
--- Comment #10 from Paul H. Hargrove PHHargrove at lbl dot gov 2012-08-13
22:54:12 UTC ---
(In reply to comment #9)
Following up on my previous experiment, I tried the same input with the xgcc
which is failing to build libdecnumber. If also
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31557
Paul H. Hargrove PHHargrove at lbl dot gov changed:
What|Removed |Added
CC||PHHargrove
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17108
Paul H. Hargrove PHHargrove at lbl dot gov changed:
What|Removed |Added
CC||PHHargrove
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142
--- Comment #13 from Paul H. Hargrove PHHargrove at lbl dot gov 2012-08-14
00:01:08 UTC ---
(In reply to comment #9)
Of course, if 'sldi' and 'slri' ARE supposed to be supported in common mode,
then this is a binutils bug.
I've confirmed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31557
--- Comment #4 from Paul H. Hargrove PHHargrove at lbl dot gov 2012-08-14
00:31:14 UTC ---
(In reply to comment #3)
FWIW, 4.8.0 20120809 w/ -O1 or higher is now using just 4 instructions instead
of 5. So, half way there.
.L.f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142
--- Comment #6 from Paul H. Hargrove PHHargrove at lbl dot gov 2012-07-31
17:59:31 UTC ---
(In reply to comment #2)
sldi and srdi are both standard PowerPC64 instructions.
IBM's Programming Environments Manual for 64-Bit Microprocessors lists
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48922
--- Comment #3 from Paul H. Hargrove PHHargrove at lbl dot gov 2011-12-16
01:42:30 UTC ---
Created attachment 26105
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26105
BUILDDIR/gcc/config.log from the problematic build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49379
--- Comment #5 from Paul H. Hargrove PHHargrove at lbl dot gov 2011-06-29
04:20:13 UTC ---
Created attachment 24629
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24629
Second (non Apple) reproducer for bug 49379
This attachment is a simple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49379
Paul H. Hargrove PHHargrove at lbl dot gov changed:
What|Removed |Added
CC||PHHargrove
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49303
Summary: ICE: vinsn_detach, at sel-sched-ir.c:1277 w/ -O3 on
ia64 in r174558
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49303
--- Comment #1 from Paul H. Hargrove PHHargrove at lbl dot gov 2011-06-06
20:07:44 UTC ---
Due to a rogue $PATH the failing gcc-4.7.0 in the report was built with a
non-standard gcc. To rule out that as a possible contributing factor, I have
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49304
Summary: ICE: code_motion_path_driver, at sel-sched.c:6573 w/
-O3 on ia64 in r174558
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48924
Summary: bugzilla: password dialog still claims 6-char minimum
length
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: trivial
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48922
Summary: invalid dwarf2 on ia64 with very old gas
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo:
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: PHHargrove at lbl dot gov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43027
--- Comment #2 from PHHargrove at lbl dot gov 2010-02-11 02:09 ---
(In reply to comment #1)
Looks related to PR 37267 but that talks about #pragma inside struct. Hmm.
Indeed this shares w/ PR 37267 the fact that the original code looks roughly
like:
enum {
#include
--- Comment #25 from PHHargrove at lbl dot gov 2009-04-07 20:39 ---
Has any progress been made on this bug?
I have hit this problem with gcc-4.3.2 on IRIX with both --disable-fixed-point
and --disable-decimal-float. Since this bug is open with a milestone of 4.3.4
I figured a switch
--- Comment #27 from PHHargrove at lbl dot gov 2009-04-07 23:39 ---
(In reply to comment #26)
Ralph,
Thanks for the quick reply.
Unfortunately, I am not in control of the machine in question and thus cannot
raise the ARG_MAX limit on my own. I will send email to the admins to see
42 matches
Mail list logo
