https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82085
--- Comment #1 from Roland B ---
Forgot to mention:
The command line I used:
/usr/local/gcc-trunk/bin/g++ -std=c++1z -Wall -Wpedantic -Wextra gcc-crash.cpp
Output:
gcc-crash.cpp:8:41: internal compiler error: Segmentation fault
using type = c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82088
Bug ID: 82088
Summary: Implicit conversion "const char *x=" to "const char
x[sizeof(...)]="
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82089
Bug ID: 82089
Summary: emit_cstore sign-extends BImode result for
STORE_FLAG_VALUE == 1
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82089
--- Comment #1 from Tom de Vries ---
Created attachment 42108
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42108&action=edit
minimal patch
This patch addresses the issue in a point-fix manner. With this patch, we
generate instead:
...
(i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82088
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82086
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81937
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82089
--- Comment #2 from Tom de Vries ---
I do wonder though about val_signbit_known_clear_p (and friends):
...
/* Test whether the most significant bit of mode MODE is clear in VAL.
Returns false if the precision of MODE is too large to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82065
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82089
--- Comment #3 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> Say that in bfin.md, we redefine cstoresi4 in the following way:
> ...
> (define_expand "cstoresi4"
> [(set (match_operand:BI 0 "")
> (match_operator:BI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82064
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords|rejects-valid |wrong-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66087
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81735
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82087
--- Comment #1 from d25fe0be@ ---
Sorry, the command invoked was missing:
```
clang++ -std=gnu++98 -fno-PIE -c -g -DIN_GCC-fno-strict-aliasing
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #14 from Romain Bossart ---
Thank you Jack, gcc-7.2.0 now compiles correctly on my i7 system (8 cores HT)
with encrypted APFS
Best regards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #15 from Jack Howarth ---
Maybe I'm just thick, but from the generated
x86_64-apple-darwin17.0.0/libstdc++-v3/include/Makefile, it is entirely unclear
to me how the stamp mechanism and the current install-headers insures that
install-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #16 from Jack Howarth ---
The component on this bug should probably be switched back off of 'target' to
'libstdc++' as the broken stamps implementation is likely just latent on other
targets because none of them have filesystems with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82087
--- Comment #2 from d25fe0be@ ---
After suppressing Clang's error about passing POD through varargs,
bootstrapping r251624 now fails with:
```
libtool: compile: /private/tmp/gcc-20170903-13173-cfn0kc/build/./gcc/xgcc
-B/private/tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82090
Bug ID: 82090
Summary: Bogus warning: ‘magic_p’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #11 from Dominique d'Humieres ---
> Where is
>
> and$0xfff0,%rsp
I cannot find it!-(
> my patch added?
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81735
Dominique d'Humieres changed:
What|Removed |Added
Blocks||68241
--- Comment #4 from Dominiq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82091
Bug ID: 82091
Summary: [5] Build failure on macOS 10.13 with Xcode 9
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: boo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82091
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |5.5
Summary|[5] Build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82091
--- Comment #2 from Francois-Xavier Coudert ---
Yes, on 6 and 7 the headers are included early, as my patch is doing here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
H.J. Lu changed:
What|Removed |Added
Attachment #41917|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #13 from H.J. Lu ---
(In reply to Dominique d'Humieres from comment #11)
> > Where is
> >
> > and$0xfff0,%rsp
>
> I cannot find it!-(
>
> > my patch added?
>
> Yes.
Please try my new patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #14 from Dominique d'Humieres ---
> Please try my new patch.
AFAICT it is not different from the one I have already applied (why the
duplications?).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
H.J. Lu changed:
What|Removed |Added
Attachment #42109|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82091
Jack Howarth changed:
What|Removed |Added
CC||howarth.at.gcc at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #16 from H.J. Lu ---
(In reply to Dominique d'Humieres from comment #14)
> > Please try my new patch.
>
> AFAICT it is not different from the one I have already applied (why the
> duplications?).
I updated it again. If it still doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81735
--- Comment #5 from Dominique d'Humieres ---
> I still see "pointer being freed was not allocated" with r233625 reverted.
But it is gone if I revert r233589.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #17 from Dominique d'Humieres ---
> I updated it again. If it still doesn't work, please show me what
> you applied.
The test now pass in 64 bit mode, but not in 32 bit one:
% /opt/gcc/gcc8w/bin/gcc /opt/gcc/work/gcc/testsuite/gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82065
--- Comment #2 from Harald Anlauf ---
(In reply to Dominique d'Humieres from comment #1)
> Confirmed on x86_64-apple-darwin16 from 4.8 up to trunk (8.0). Note that the
> error is given by the as. Is it the case on linux?
Yes.
Note that the erro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #18 from H.J. Lu ---
(In reply to Dominique d'Humieres from comment #17)
> > I updated it again. If it still doesn't work, please show me what
> > you applied.
>
> The test now pass in 64 bit mode, but not in 32 bit one:
>
> % /opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82086
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #19 from Dominique d'Humieres ---
> Do you know why it fails in 32-bit mode?
Nope! Are you sure that %esp is the stack in 32 bit mode?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #20 from H.J. Lu ---
(In reply to Dominique d'Humieres from comment #19)
> > Do you know why it fails in 32-bit mode?
>
> Nope! Are you sure that %esp is the stack in 32 bit mode?
Yes, %esp is correct for 32-bit mode. Please compil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82092
Bug ID: 82092
Summary: gcc fails to link genmodes on darwin
(cfiStartsArray[i] != cfiStartsArray[i-1])
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82093
Bug ID: 82093
Summary: gfortran.dg/vect/pr70043.f90 contains out-of-bounds
references
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81942
Paolo Carlini changed:
What|Removed |Added
CC|paolo.carlini at oracle dot com|
--- Comment #13 from Paolo Carli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #21 from Dominique d'Humieres ---
% /opt/gcc/gcc8w/bin/gcc /opt/gcc/work/gcc/testsuite/gcc.dg/torture/pr25967-1.c
-m32 -g
% lldb a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (i386).
(lldb) run
Process 25578 lau
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #22 from Dominique d'Humieres ---
The test succeeds with -m32 (but fails with -m64) with the following change
+ /* Align exception handler stack to 16 bytes. */
+ asm ("and$-8, %" STACK_POINTER ";\
+push $" S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #23 from H.J. Lu ---
(In reply to Dominique d'Humieres from comment #22)
> The test succeeds with -m32 (but fails with -m64) with the following change
>
> + /* Align exception handler stack to 16 bytes. */
> + asm ("and $-8, %" S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82094
Bug ID: 82094
Summary: error: inlining failed in call to always_inline
‘_mm512_permutexvar_epi8’
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: norma
44 matches
Mail list logo
