[Bug target/64345] [SH] Improve single bit extraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64345
--- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org ---
A recent change in the middle end has triggered this:
FAIL: gcc.target/sh/pr54236-1.c scan-assembler-times negc 2
The test
int
test_07 (int *vec)
{
/* Must not see a 'sett' or 'addc' here.
This is a case where combine tries to produce
'a + (0 - b) + 1' out of 'a - b + 1'.
On non-SH2A there is a 'tst + negc', on SH2A a 'bld + movt'. */
int z = vec[0];
int vi = vec[1];
int zi = vec[2];
if (zi != 0 z -1)
vi -= (((vi 7) 0x01) 1) - 1;
return vi;
}
fails to produce the expected tst + negc sequence.
A reduced case is:
int test (int vi)
{
return vi - (((vi 6) 0x01) 1);
}
-m2a -O2 (gcc 5):
bld #6,r4
movtr0
rts
add r0,r0
trunk:
mov #-5,r1
mov r4,r0
shldr1,r0
rts
and #2,r0
-m4 -O2 (gcc 5):
mov r4,r0
tst #64,r0
mov #-1,r0
negcr0,r0
rts
add r0,r0
trunk:
mov #-5,r1
mov r4,r0
shldr1,r0
rts
and #2,r0
For the more complex expression
int test (int vi)
{
return vi - (((vi 6) 0x01) 1) - 1;
}
-m4 -O2 (gcc 5):
mov r4,r0
mov #-1,r1
tst #64,r0
negcr1,r1
add r1,r1
rts
subcr1,r0
trunk:
mov #-5,r1
mov r4,r0
shldr1,r0
sett
and #2,r0
subcr0,r4
rts
mov r4,r0
It seems the zero_extract patterns are not used for this anymore. Instead
combine is looking for something like
(set (reg:SI 168 [ D.1649 ])
(and:SI (lshiftrt:SI (reg:SI 4 r4 [ vi ])
(const_int 5 [0x5]))
(const_int 2 [0x2])))
This pattern should be added as a zero_extract variant.
[Bug c/66903] The gcc 4.9.2 crashes when processing declarations such as: int (( ... (x) ... ))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66903 --- Comment #4 from Salva Peiró speirofr at gmail dot com --- Confirmed, the cause of the crash is the parser _cpp_lex_direct() consuming the default 8 MB Linux stack. Indeed, ulimit -s shows the stack size limit is set to 8192 KB, After recompiling with ulimit -s unlimited, the gcc compilation succeeds without crashes. Thanks for the explanation the time to look at this, PS: I raised the issue mainly because I was unsure of causes that lead to the crash.
[Bug target/54236] [SH] Improve addc and subc insn utilization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54236
--- Comment #16 from Oleg Endo olegendo at gcc dot gnu.org ---
Created attachment 36012
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36012action=edit
addsicc pattern
(In reply to Oleg Endo from comment #9)
The following function compiled with -O2
unsigned int check (unsigned int x)
{
return x == 0 ? 1 : x;
}
results in:
tst r4,r4
bt/s.L7
mov #1,r0
mov r4,r0
.L7:
rts
nop
Writing it as:
unsigned int check (unsigned int x)
{
return x + (x == 0);
}
results in:
tst r4,r4
mov #0,r0
rts
addcr4,r0
It seems that ifcvt is trying to utilize the 'addmodecc' standard name
pattern. If the 2nd operand of the conditional addition is a constant 1 or
-1 the addcc insn can be implemented via addc or subc without a branch.
The attached patch adds support for the addsicc pattern and a few other
improvements. However, the first case above doesn't see any improvement. It
seems that it's a missed ifcvt optimization.
[Bug target/63304] Aarch64 pc-relative load offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304
--- Comment #14 from David Abdurachmanov david.abdurachmanov at gmail dot com
---
I hit another two cases of this.
1. g2root tool, which converts GEANT geometry to ROOT geometry. It create a
single function, which contains lots of descriptions of material, shapes, etc.
all describing some 3D objects and physical properties. These can be very huge.
Also could think of MILL computing as possible example. They use C++ as they
assembler (at least for simulation). Thus you have something like:
void somefunc(void) {
add(b0, b1);
add(b2, b3);
...
}
IIRC, by compiling it they generate a simulator to run this program on specific
CPU.
2. mcfm 6.3 package, to be precise: mcfm-6.3/src/WW/triangle11new.f
triangle11new.s: Assembler messages:
triangle11new.s:587: Error: pc-relative load offset out of range
triangle11new.s:592: Error: pc-relative load offset out of range
..
587 ldr x0, .LC2
588 fmovd0, x2
589 fmovd1, x0
590 fdivd0, d0, d1
591 fmovx2, d0
592 ldr x0, .LC2
..
346645 .LC2:
346646 .word 0
346647 .word 1073741824
346648 .align 3
..
Distance between ldr instruction and .LC2 is 346058 assembly lines.
Here is the source file:
https://github.com/cms-externals/MCFM/blob/master/src/WW/triangle11new.f (just
1355 sloc).
It's those huge computations, which are killing it. Similar issue as in
OpenLoops package.
[Bug target/64345] [SH] Improve single bit extraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64345
--- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #2)
The following pattern seems to fix the test case.
===
--- gcc/config/sh/sh.md (revision 225987)
+++ gcc/config/sh/sh.md (working copy)
@@ -14220,6 +14220,31 @@
[(set (reg:SI T_REG)
(zero_extract:SI (match_dup 0) (const_int 1) (match_dup 1)))])
+(define_insn_and_split *zero_extract_3
+ [(set (match_operand:SI 0 arith_reg_dest)
+ (and:SI (lshiftrt:SI (match_operand:SI 1 arith_reg_operand)
+(match_operand 2 const_int_operand))
+ (match_operand 3 const_int_operand)))
+ (clobber (reg:SI T_REG))]
+ TARGET_SH1 can_create_pseudo_p ()
+exact_log2 (INTVAL (operands[3])) = 0
+ #
+ 1
+ [(const_int 0)]
+{
+ int rshift = INTVAL (operands[2]);
+ int lshift = exact_log2 (INTVAL (operands[3]));
+
+ rtx tmp = gen_reg_rtx (SImode);
+ emit_insn (gen_rtx_PARALLEL (VOIDmode,
+gen_rtvec (2,
+ gen_rtx_SET (tmp,
+ gen_rtx_ZERO_EXTRACT (SImode, operands[1], const1_rtx,
+GEN_INT (rshift + lshift))),
+ gen_rtx_CLOBBER (VOIDmode, get_t_reg_rtx ();
+ emit_insn (gen_ashlsi3 (operands[0], tmp, GEN_INT (lshift)));
+})
+
;; -
;; SH2A instructions for bitwise operations.
;; FIXME: Convert multiple instruction insns to insn_and_split.
However, in some cases it might indeed be better to emit a shift-and sequence,
especially if the shift value is 1,2,8,16.
For instance
return (((vi 6) 0x01) 3);
results in
mov r4,r0
tst #64,r0
mov #-1,r0
negcr0,r0
shll2 r0
rts
add r0,r0
which is better as:
mov r4,r0
shll2 r0
shlrr0
rts
and #8,r0
Even more so when the bit test constant doesn't fit into 8 bits:
return (((vi 10) 0x01) 1);
mov.w .L2,r1
mov #-1,r0
tst r1,r4
negcr0,r0
rts
add r0,r0
.align 1
.L2:
.short 1024
better:
mov r4,r0
shlr8 r0
shlrr0
rts
and #2,r0
Generally, it seems better to use an shift-and sequence, unless the tst-negc
sequence can simplify the trailing shift for SH variants without dynamic
shifts.
[Bug c++/66934] Compiler accepting ill-formed program with extern variable declarations and using-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66934 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- I think we could combine most of your reports into one or two PRs since they're all related and fixing them one by one would probably not be very efficient.
[Bug preprocessor/66932] Preprocessor includes wrong header file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66932 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-07-19 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Works for me too, with any version. gcc_bug$ which gcc ~/gcc/4.9.3/bin/gcc gcc_bug$ cd gas gas$ ./compile.sh ^[[3~In file included from ./../include/alloca-conf.h:2:0, from as.h:2, from as.c:2: ./config.h:2:2: warning: #warning You have included the correct include file [-Wcpp] #warning You have included the correct include file ^ Please provide the output of: echo $CPATH $C_INCLUDE_PATH
[Bug c/66918] Disable inline function declared but never defined warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66918 --- Comment #4 from Eugene Zelenko eugene.zelenko at gmail dot com --- (In reply to Manuel López-Ibáñez from comment #3) Does Clang have an option for this? GCC could use the same name. (The same warning exists in the C++ FE, thus it should be controlled by the same option). I tried small example with Clang 3.7 https://gcc.godbolt.org and it looks like it doesn't have such warning (I used -Weverything -std=C++11 and C++14). GCC already has -Wunused-function and it seems reasonable to extend it to inline functions.
[Bug middle-end/64394] ICE: in build_linearized_memory_access, at graphite-interchange.c:121 (isl_constraint.c:558: expecting integer value) with -floop-interchange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64394 --- Comment #4 from Jana Saout jana at saout dot de --- Indeed - I've applied the patch on top of 5.2.0 and I can't reproduce the issue anymore with any of the packages that have failed before. Looking fine.
[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 --- Comment #5 from Keith Marshall keith.marshall at mailinator dot com --- (In reply to kargl from comment #4) Update title. The code in question is #ifdef HAVE_UMASK /* Temporarily set the umask such that the file has 0600 permissions. */ mode_mask = umask (S_IXUSR | S_IRWXG | S_IRWXO); #endif MinGW appears to define HAVE_UMASK, but MinGW seems to lack a correctly written umask(3). MinGW inherits its umask() implementation from Microsoft, in the shape of whatever MSVCRT.DLL provides; (and yes, at one time Microsoft decided to rename their umask() implementation to _umask(), but MinGW has always mapped those renames back to their originals, for backwards compatibility). So, the bug is that you gratuitously assume that any umask() implementation should conform to POSIX, even when the platform is not POSIX. IF you aim to support non-POSIX platforms, (as you do with the mingw32 target), you must be prepared to handle non-POSIX implementations, such as this umask() -- _umask(), which is documented at https://msdn.microsoft.com/en-us/library/5axxx3be.aspx
[Bug c++/66934] Compiler accepting ill-formed program with extern variable declarations and using-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66934 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Problem report i.e. bugzilla bug.
[Bug c/66938] New: using bool as destination in overflow checkers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66938 Bug ID: 66938 Summary: using bool as destination in overflow checkers Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: rv at rasmusvillemoes dot dk Target Milestone: --- Playing around with the __builtin_*_overflow checkers, I noticed that when the third argument is pointer to _Bool one gets error: argument 3 in call to function '__builtin_add_overflow' does not have pointer to integer type. Technically, _Bool _is_ an integer type. I can't really think of a situation where one would want to do arithmetic on _Bools, or to know if the result of a computation is 0 or 1, so this is mostly about the wording of the error message [also, does not have should probably be is not]. But maybe adding support for _Bools is easy enough to just do it for completeness.
[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 --- Comment #6 from Keith Marshall keith.marshall at mailinator dot com --- (In reply to kargl from comment #4) Update title. The code in question is #ifdef HAVE_UMASK /* Temporarily set the umask such that the file has 0600 permissions. */ mode_mask = umask (S_IXUSR | S_IRWXG | S_IRWXO); #endif MinGW appears to define HAVE_UMASK, but MinGW seems to lack a correctly written umask(3). Just for the record: MinGW has had access to Microsoft's umask() implementation for a very long time; HAVE_UMASK has always been defined, when compiling the mingw32 builds of GCC. However, this particular block of code is encapsulated within an outer #ifdef HAVE_MKSTEMP block, and it is only recently that MinGW has provided an implementation of mkstemp(), (Microsoft do not offer one), which has caused HAVE_MKSTEMP to become defined, so exposing this (presumably long-standing) bug.
[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #7 from kargl at gcc dot gnu.org --- (In reply to Keith Marshall from comment #6) (In reply to kargl from comment #4) Update title. The code in question is #ifdef HAVE_UMASK /* Temporarily set the umask such that the file has 0600 permissions. */ mode_mask = umask (S_IXUSR | S_IRWXG | S_IRWXO); #endif MinGW appears to define HAVE_UMASK, but MinGW seems to lack a correctly written umask(3). Just for the record: MinGW has had access to Microsoft's umask() implementation for a very long time; HAVE_UMASK has always been defined, when compiling the mingw32 builds of GCC. However, this particular block of code is encapsulated within an outer #ifdef HAVE_MKSTEMP block, and it is only recently that MinGW has provided an implementation of mkstemp(), (Microsoft do not offer one), which has caused HAVE_MKSTEMP to become defined, so exposing this (presumably long-standing) bug. So add #define S_IRWXG 0 #define S_IRWXO 0 to the header file wherever mingw defines the available mask bits for umask(3). The bug is clearly in mingw were it gratuitously maps umask() to _umask() without properly adding the mappings for the mode_t argument bits of umask(3).
[Bug c++/66934] Compiler accepting ill-formed program with extern variable declarations and using-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66934 --- Comment #2 from Anders Granlund anders.granlund.0 at gmail dot com --- (In reply to Jonathan Wakely from comment #1) I think we could combine most of your reports into one or two PRs since they're all related and fixing them one by one would probably not be very efficient. What is a PR?
[Bug libgcc/66939] New: build error gcc-5.2.0/libgcc/libgcc2.c:1955:6 internal compiler error: in real_from_string, at real.c:2078
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66939 Bug ID: 66939 Summary: build error gcc-5.2.0/libgcc/libgcc2.c:1955:6 internal compiler error: in real_from_string, at real.c:2078 Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: richardbroadbent+gcc at gmail dot com Target Milestone: --- Attempting to build gcc 5.2.0 on macbook pro osx 10.6, downloaded gcc-5.2.0.tar.bz2 from UK mirrorservice.org mirror extracted using: tar -xjf gcc-5.2.0.tar.bz2 configured using ../gcc-5.2.0/configure --enable-languages=c,c++,fortran --prefix=/usr/local attempted build using: make -j2 received error: /Users/RB1109/gcc_build/./gcc/xgcc -B/Users/RB1109/gcc_build/./gcc/ -B/usr/local/x86_64-apple-darwin10.8.0/bin/ -B/usr/local/x86_64-apple-darwin10.8.0/lib/ -isystem /usr/local/x86_64-apple-darwin10.8.0/include -isystem /usr/local/x86_64-apple-darwin10.8.0/sys-include-g -O2 -m32 -O2 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -pipe -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -pipe -fno-common -I. -I. -I../../.././gcc -I../../../../gcc-5.2.0/libgcc -I../../../../gcc-5.2.0/libgcc/. -I../../../../gcc-5.2.0/libgcc/../gcc -I../../../../gcc-5.2.0/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _multc3.o -MT _multc3.o -MD -MP -MF _multc3.dep -DL_multc3 -c ../../../../gcc-5.2.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS ../../../../gcc-5.2.0/libgcc/libgcc2.c: In function ‘__mulxc3’: ../../../../gcc-5.2.0/libgcc/libgcc2.c:1955:6: internal compiler error: in real_from_string, at real.c:2078 a = COPYSIGN (isinf (a) ? 1 : 0, a); ^ ../../../../gcc-5.2.0/libgcc/libgcc2.c:1955:6: internal compiler error: Abort trap xgcc: internal compiler error: Abort trap (program cc1) Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[5]: *** [_mulxc3.o] Error 4 make[5]: *** Waiting for unfinished jobs
[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 --- Comment #8 from Keith Marshall keith.marshall at mailinator dot com --- (In reply to kargl from comment #7) So add #define S_IRWXG 0 #define S_IRWXO 0 to the header file wherever mingw defines the available mask bits for umask(3). The bug is clearly in mingw were it gratuitously maps umask() to _umask() without properly adding the mappings for the mode_t argument bits of umask(3). Absolutely not! Those bits are utterly irrelevant for the windows (MinGW) platform; to add them would be do nothing more than create confusion. The mask bits for umask(), on the windows platform are S_IREAD | S_IWRITE; those are the only mask bits YOUR code should be passing to non-POSIX umask(5axxx3be.aspx). This is NOT a MinGW bug; it's a GCC bug, and that's where it should be fixed. Until you do fix it, I have my work-around, (which I'm perfectly willing to publish in MinGW forked source for GCC, prominently commented as a ghastly hack to circumvent a gross upstream GCC bug).
[Bug driver/66732] ISL 0.15 released, has breaking changes to gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66732 --- Comment #2 from jamespharvey20 at gmail dot com --- Patches https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01162.html and https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01506.html Appear to resolve the issue. Compiling with ISL 0.15 just fine now.
[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that mkstemp() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 --- Comment #2 from Keith Marshall keith.marshall at mailinator dot com --- (In reply to kargl from comment #1) The name of the language is Fortran. The language has been called Fortran since 1988 or so. It was always FORTRAN, in the days when I actually used the language, but how you choose to capitalize it, or not, is completely irrelevant. The correct fix would be to add test to configure to define HAVE_S_IRWXG and HAVE_S_IRWXO. Of course it would, but I'm not going to dirty my hands with your autoconf code; this is your bug, and that is definitively your responsibility. A better fix would be for MingW32 to conform to POSIX. No, it most definitely would not; that is never going to happen. MinGW is definitively aimed at Microsoft Windows compatibility. Windows is not POSIX, and nor is MinGW; nor will it ever be, nor will it even aspire to be. S_IRWXG and S_IRWXO have no place in the windows environment; it would be wrong for MinGW to define them, (even if an appropriate pseudo-definition were ever proposed), just as it is wrong for you to assume that availability of mkstemp() implies that they should be defined.
[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that mkstemp() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 --- Comment #3 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Sun, Jul 19, 2015 at 05:29:35PM +, keith.marshall at mailinator dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 --- Comment #2 from Keith Marshall keith.marshall at mailinator dot com --- (In reply to kargl from comment #1) The name of the language is Fortran. The language has been called Fortran since 1988 or so. It was always FORTRAN, in the days when I actually used the language, but how you choose to capitalize it, or not, is completely irrelevant. Ignorance is bliss.
[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that mkstemp() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 Severity|normal |enhancement
[Bug inline-asm/49611] Inline asm should support input/output of flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611
--- Comment #15 from Jeremy gcc.hall at gmail dot com ---
Perhaps the optimizer can reduce seta; test; jnz to ja since the
compiler now knows the intention. In which case this is a great solution.
On 17 July 2015 at 22:24, gccbugzilla at limegreensocks dot com
gcc-bugzi...@gcc.gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611
--- Comment #14 from David gccbugzilla at limegreensocks dot com ---
(In reply to Jeremy from comment #12)
It probably does a setcc on x86 which doesn't really gain much
I don't have a 6.0 build to test with yet, but I don't believe that's quite
correct. Looking at the testsuite that got checked in with it, we see
both:
asm-flag-2.c:
/* { dg-final { scan-assembler seta } } */
asm-flag-3.c:
/* { dg-final { scan-assembler ja } } */
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug libfortran/66936] New: io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that mkstemp() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 Bug ID: 66936 Summary: io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that mkstemp() is available Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: keith.marshall at mailinator dot com Target Milestone: --- Created attachment 36013 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36013action=edit Kludge to work around issue for mingw32 When building GCC, with FORTRAN language support, for mingw32 with the mingwrt-3.21+ runtime library from MinGW.org installed, the build fails in libgfortran/io/unix.c, because the tempfile_open() function gratuitously assumes that, if HAVE_MKSTEMP is defined, then it must invoke: mode_mask = umask (S_IXUSR | S_IRWXG | S_IRWXO); regardless of whether or not those access mode flags are defined. Of course, the assumption is invalid: while S_IXUSR may have some semblance of meaning on a windows host, and is defined, S_IRWXG and S_IRWXO are meaningless, and are not. Now, I can kludge around this, with the attached patch, but I suspect that it doesn't represent a true solution.
[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that mkstemp() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Keith Marshall from comment #0) Created attachment 36013 [details] Kludge to work around issue for mingw32 When building GCC, with FORTRAN language support, for mingw32 with the mingwrt-3.21+ runtime library from MinGW.org installed, the build fails in libgfortran/io/unix.c, because the tempfile_open() function gratuitously assumes that, if HAVE_MKSTEMP is defined, then it must invoke: mode_mask = umask (S_IXUSR | S_IRWXG | S_IRWXO); regardless of whether or not those access mode flags are defined. Of course, the assumption is invalid: while S_IXUSR may have some semblance of meaning on a windows host, and is defined, S_IRWXG and S_IRWXO are meaningless, and are not. Now, I can kludge around this, with the attached patch, but I suspect that it doesn't represent a true solution. The name of the language is Fortran. The language has been called Fortran since 1988 or so. The correct fix would be to add test to configure to define HAVE_S_IRWXG and HAVE_S_IRWXO. A better fix would be for MingW32 to conform to POSIX.
[Bug c++/66937] New: Do not compare constraints for unconstrained template template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66937 Bug ID: 66937 Summary: Do not compare constraints for unconstrained template template parameters Product: gcc Version: c++-concepts Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rbock at eudoxos dot de CC: andrew.n.sutton at gmail dot com Target Milestone: --- Created attachment 36014 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36014action=edit copy tuple args implementation and test code that currently fails to compile I have a template that takes a std::tuple (source) and copies its arguments into another template (sink), see attached code. templatetypename Tuple, templatetypename... class Sink using copy_tuple_args = ... The copy_tuple_args template is supposed to be generic, not caring about the nature of the copied arguments or the sink. This works fine as long as the sink is not constrained, e.g. if the sink is another tuple. But if the sink has constraints, templateColumn... C struct column_list; then both N4377 and the current gcc concepts implementation (revision 225987) do not allow copying, because the argument (column_list) is more constrained than the unconstrained parameter (Sink). This seems to be a rather unfortunate rule. I believe that copy_tuple_args is a reasonable use case (which works just fine with C++11). It will stop working as soon as concepts start to get used. In private communication Andrew Sutton agreed that this is an issue. I am going to file a defect report for the Concepts TS. Andrew intends to discuss this in Kona. Andrew's proposed solution is to not compare constraints for unconstrained template template parameters. This will certainly fix the problem for me :-) Best, Roland
[Bug preprocessor/66932] Preprocessor includes wrong header file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66932 --- Comment #3 from Michael McWilliam pilot.mm at gmail dot com --- (In reply to Jonathan Wakely from comment #2) Works for me too, with any version. gcc_bug$ which gcc ~/gcc/4.9.3/bin/gcc gcc_bug$ cd gas gas$ ./compile.sh ^[[3~In file included from ./../include/alloca-conf.h:2:0, from as.h:2, from as.c:2: ./config.h:2:2: warning: #warning You have included the correct include file [-Wcpp] #warning You have included the correct include file ^ Please provide the output of: echo $CPATH $C_INCLUDE_PATH CPATH is empty C_INCLUDE_PATH is: :/usr/local/atlas/include:/usr/local/atlas/include/atlas:/usr/local/atlas/include:/usr/local/atlas/include/atlas So when I remove the leading : in C_INCLUDE_PATH and delete the duplicated entries, magically it works. So clearly there is an error on my machine on the way environment variables are being set... I will have to fix that... I suppose the problem is a NULL path in the variable leads to undefined behaviour... maybe gcc could be improved to ignore null paths or spit a warning or something?
[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 kargl at gcc dot gnu.org changed: What|Removed |Added Summary|io/unix.c gratuitously uses |io/unix.c gratuitously uses |S_IRWXG and S_IRWXO on the |S_IRWXG and S_IRWXO on the |basis that mkstemp() is |basis that umask() is |available |available --- Comment #4 from kargl at gcc dot gnu.org --- Update title. The code in question is #ifdef HAVE_UMASK /* Temporarily set the umask such that the file has 0600 permissions. */ mode_mask = umask (S_IXUSR | S_IRWXG | S_IRWXO); #endif MinGW appears to define HAVE_UMASK, but MinGW seems to lack a correctly written umask(3).
[Bug middle-end/64327] ../../gcc/gcc/rtlanal.c:4881:48: runtime error: shift exponent 4294967295 is too large for 64-bit type 'long unsigned int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64327 --- Comment #5 from Vittorio Zecca zeccav at gmail dot com --- In 5.2.0 too.
[Bug c++/66941] New: Missing diagnostic extraneous template parameter list in template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66941
Bug ID: 66941
Summary: Missing diagnostic extraneous template parameter list
in template specialization
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: miyuki at gcc dot gnu.org
Target Milestone: ---
Consider this testcase:
$cat genpreds1_min.cc
template typename
class A;
template int
struct B;
template typename
struct C;
template
template int N
struct C B N
{
templatetypename T
A B N
m_fn(T);
};
template int N
template typename T
A B N
C B N ::m_fn (T)
{
}
EDG rejects it with the following error:
/opt/intel/bin/icpc -c genpreds1_min.cc
genpreds1_min.cc(22): error: incomplete type is not allowed
C B N ::m_fn (T)
^
genpreds1_min.cc(22): error: template argument list must match the parameter
list
C B N ::m_fn (T)
^
compilation aborted for genpreds1_min.cc (code 2)
Clang gives warning:
/opt/clang-trunk/bin/clang++ -c genpreds1_min.cc
genpreds1_min.cc:10:1: warning: extraneous template parameter list in template
specialization
template
^~~
1 warning generated.
But GCC silently accepts this code. I suppose that GCC could warn about:
template typename
struct base {};
template typename
struct s {};
template
template typename T
struct base s T {};
like Clang does (note: in this case EDG accepts the code without
warnings/errors).
[Bug rtl-optimization/66940] New: ifcvt.c:1907 signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66940
Bug ID: 66940
Summary: ifcvt.c:1907 signed integer overflow
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
/* must be compiled with -O */
/* in noce_get_alt_condition */
/*gcc-5.2.0/gcc/ifcvt.c:1907: runtime error: signed integer overflow:
9223372036854775807 + 1 cannot be represented in type 'long int'*/
/* gcc source line if (actual_val == desired_val + 1)*/
/* double check with gcc_assert(desired_val+1desired_val); immediately
before*/
long foo(void)
{
long ival = 0;
int cp ;
if (cp) ival = -1;
if (ival 0) return -0x7fffL - 1;
return 0x7fffL;
}
[Bug target/64833] [SH]: Error: pcrel too far when compiling imagemagick and graphicsmagick on Debian sh4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64833 --- Comment #25 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- (In reply to Kazumoto Kojima from comment #24) Fixed. Can confirm, graphicsmagick just built successfully for the first time since 2013 :). http://buildd.debian-ports.org/status/fetch.php?pkg=graphicsmagickarch=sh4ver=1.3.20-3%2Bdeb8u1stamp=1436877116
[Bug target/66917] ARM: NEON: memcpy compiles to vld1 and vst1 with incorrect alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
--- Comment #2 from Mikael Pettersson mikpelinux at gmail dot com ---
This test case changed behaviour twice in the 4.7-4.8 development cycle.
First r185807 broke it by replacing code for unaligned memory accesses with
code requiring more alignment than present in the source:
--- pr66917.s-r185806 2015-07-19 17:16:23.536116155 +0200
+++ pr66917.s-r185807 2015-07-19 17:13:23.016388416 +0200
@@ -17,42 +17,13 @@
.global test_neon_load_store_alignment
.type test_neon_load_store_alignment, %function
test_neon_load_store_alignment:
- @ args = 0, pretend = 0, frame = 32
+ @ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
- mov r3, r0
- stmfd sp!, {r4, r5, r6, r7}
- mov r7, r1
- ldr r0, [r0, #0]@ unaligned
- mov r6, r2
- sub sp, sp, #32
- ldr r1, [r3, #4]@ unaligned
- mov r5, sp
- ldr r2, [r3, #8]@ unaligned
- add r4, sp, #16
- ldr r3, [r3, #12] @ unaligned
- mov ip, sp
- stmia r5!, {r0, r1, r2, r3}
- ldr r0, [r7, #0]@ unaligned
- ldr r1, [r7, #4]@ unaligned
- ldr r2, [r7, #8]@ unaligned
- ldr r3, [r7, #12] @ unaligned
- flddd16, [sp, #0] @ int
- flddd19, [sp, #8] @ int
- stmia r4!, {r0, r1, r2, r3}
- flddd18, [sp, #16] @ int
- veord17, d16, d18
- flddd18, [sp, #24] @ int
- fstdd17, [sp, #0] @ int
- veord16, d19, d18
- fstdd16, [sp, #8] @ int
- ldmia ip!, {r0, r1, r2, r3}
- str r0, [r6, #0]@ unaligned
- str r1, [r6, #4]@ unaligned
- str r2, [r6, #8]@ unaligned
- str r3, [r6, #12] @ unaligned
- add sp, sp, #32
- ldmfd sp!, {r4, r5, r6, r7}
+ vldmia r0, {d18-d19}
+ vldmia r1, {d16-d17}
+ veorq8, q9, q8
+ vstmia r2, {d16-d17}
bx lr
.size test_neon_load_store_alignment,
.-test_neon_load_store_alignment
.section.text.startup,ax,%progbits
On Linux, this code SIGBUSes because the kernel can't fix up the first
misaligned access:
[292105.326391] Alignment trap: not handling instruction ecd02b04 at
[8e84]
[292105.396370] Unhandled fault: alignment exception (0x001) at 0x0008b109
Then r191399 changed it again by replacing the vldm/vstm instructions with
vld1.64/vst1.64 instructions:
--- pr66917.s-r191398 2015-07-19 19:12:15.815583139 +0200
+++ pr66917.s-r191399 2015-07-19 19:08:36.416037498 +0200
@@ -20,10 +20,10 @@
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
- vldmia r0, {d18-d19}
- vldmia r1, {d16-d17}
+ vld1.64 {d18-d19}, [r0:64]
+ vld1.64 {d16-d17}, [r1:64]
veorq8, q9, q8
- vstmia r2, {d16-d17}
+ vst1.64 {d16-d17}, [r2:64]
bx lr
.size test_neon_load_store_alignment,
.-test_neon_load_store_alignment
.section.text.startup,ax,%progbits
These instructions still fault, but the kernel recognizes them and fixes up the
alignment faults (if suitably configured).
If I compile the test case for x86_64 w/ -O3 -mavx, the compiler generates
vmovdqu instructions which permit unaligned addresses. So I suspect a target
bug.
