https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66769
--- Comment #2 from fiesh at zefix dot tv ---
A friend checked for me, 5.1.0 also appears affected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66720
--- Comment #4 from amker at gcc dot gnu.org ---
Author: amker
Date: Mon Jul 6 05:57:56 2015
New Revision: 225443
URL: https://gcc.gnu.org/viewcvs?rev=225443&root=gcc&view=rev
Log:
PR tree-optimization/66720
* gcc.dg/vect/pr4805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65914
Markus Trippelsdorf changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61321
--- Comment #7 from Markus Trippelsdorf ---
Pedro could you please ping your patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61321
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65732
Markus Trippelsdorf changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20150705 (experimental) [trunk revision 225420] (GCC)
$
$ gcc-trunk -Os small.c; ./a.out
$ gcc-5.1 -O2 small.c; ./a.out
$
$ gcc-trunk -O2 small.c
small.c: In function ‘fn4’:
small.c:44:1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65914
--- Comment #11 from Bill Schmidt ---
Author: wschmidt
Date: Mon Jul 6 02:08:59 2015
New Revision: 225442
URL: https://gcc.gnu.org/viewcvs?rev=225442&root=gcc&view=rev
Log:
[gcc]
2015-07-05 Bill Schmidt
Backport from mainline r2247
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65914
--- Comment #10 from Bill Schmidt ---
Author: wschmidt
Date: Mon Jul 6 02:07:49 2015
New Revision: 225441
URL: https://gcc.gnu.org/viewcvs?rev=225441&root=gcc&view=rev
Log:
[gcc]
2015-07-05 Bill Schmidt
Backport from mainline r2247
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66771
--- Comment #4 from H.J. Lu ---
Clang 3.7:
/export/build/gnu/llvm-clang-x32-bootstrap-cmake/stage1/build-x86_64-linux-gnux32/bin/clang
-c -O2 foo.cc
gnu-ivb-1:pts/1[124]>
/export/build/gnu/llvm-clang-x32-bootstrap-cmake/stage1/build-x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66771
--- Comment #3 from H.J. Lu ---
[hjl@gnu-ivb-1 build_base_lnx32e-gcc.]$ cat foo.cc
#include
char buf[300];
bool readLine(std::istream& m_input)
{
if (m_input.getline(buf, sizeof(buf)) == 0)
return false;
return true;
}
[hjl@gnu-ivb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66771
--- Comment #2 from H.J. Lu ---
It was caused by r215571.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #47 from John Paul Adrian Glaubitz ---
Well, now I just compiled both procps and grep with the latest toolchain
(gcc-4.9_4.9.3 and binutils_2.25-9) from a pristine tarball with no Debian
patches applied and *outside* of the build root
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61864
--- Comment #5 from Eric Gallager ---
Created attachment 35915
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35915&action=edit
test case demonstrating different switch-related warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61864
--- Comment #4 from Eric Gallager ---
Actually, after giving this some more thought, and reading the GCC
documentation some more, I came up with some ideas for a compromise that could
allow both -Wswitch-default and -Wcovered-switch-default to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #46 from John Paul Adrian Glaubitz ---
Furthermore, gcc also built a version of grep that is broken and simply refuses
to read any options:
root@tirpitz:..grep-test2/bin> ls
egrep fgrep grep
root@tirpitz:..grep-test2/bin> ./grep
U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65732
--- Comment #6 from Mikhail Maltsev ---
There is a patch proposed by Pedro Alves for PR61321, and it fixes all
testcases mentioned here, but the patch did not get into mainline
unfortunately.
Updated testcases (valid with applied patch, cause seg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66759
--- Comment #2 from Mikhail Maltsev ---
(In reply to kugan from comment #1)
> Most likely started with r225375
Indeed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #45 from John Paul Adrian Glaubitz ---
(In reply to Kazumoto Kojima from comment #44)
> Not likely. The sane gmp/mpfr/mpc libraries are needed, though.
Hmm, so the gcc I built is still broken. Many packages compiled with it still
se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383
--- Comment #22 from H.J. Lu ---
(In reply to Andy Lutomirski from comment #21)
> $ touch foo.c
> $ gcc -c -mno-sse -mpreferred-stack-boundary=3 -mincoming-stack-boundary=3
> foo.c
> foo.c:1:0: error: -mincoming-stack-boundary=3 is not between 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66771
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383
--- Comment #21 from Andy Lutomirski ---
(In reply to H.J. Lu from comment #20)
> (In reply to Andy Lutomirski from comment #19)
> > I don't think the fix is correct.
> >
> > This works:
> >
> > gcc -mno-sse -mpreferred-stack-boundary=3 ...
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66771
Bug ID: 66771
Summary: [5 Regression] -std=c++11 doesn't work
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383
--- Comment #20 from H.J. Lu ---
(In reply to Andy Lutomirski from comment #19)
> I don't think the fix is correct.
>
> This works:
>
> gcc -mno-sse -mpreferred-stack-boundary=3 ...
>
> This does not:
>
> gcc -mno-sse -mpreferred-stack-bounda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66770
Bug ID: 66770
Summary: [6 Regression] 252.eon in SPEC CPU 2000 failed to
build
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66769
--- Comment #1 from fiesh at zefix dot tv ---
Sorry, the above output was for 4.9.2 on a different host, mixed up when I ran
several tests. For 4.9.3:
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3/g++
Target: x86_64-pc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66769
Bug ID: 66769
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63930
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383
Andy Lutomirski changed:
What|Removed |Added
CC||luto at mit dot edu
--- Comment #19 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66556
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66729
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolutio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63930
--- Comment #3 from Harald Anlauf ---
(In reply to Harald Anlauf from comment #2)
> I think that there is a fundamental need to rewrite the handling of
> runtime errors in gfortran. Since 4.7 I do often not get useful
> backtraces with certain k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63930
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66523
--- Comment #7 from Iain Sandoe ---
(In reply to m...@gcc.gnu.org from comment #6)
> Another proposal, any symbol with an 'L.*' spelling should be not so marked,
> as these can never be used this way. Seems like we should have a predicate
> to c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66757
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |6.0
Summary|wrong code at -O1 and a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35514
--- Comment #2 from H.J. Lu ---
A patch is posted at
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00284.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66523
mrs at gcc dot gnu.org changed:
What|Removed |Added
CC||mrs at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66768
--- Comment #2 from Armin Rigo ---
Actually "gcc -O1 -fno-tree-loop-optimize bug1.c -S" also restores the %gs
prefix. I suspect however that this flag implies "-fno-ivopts", or something.
I found no other "-fno-xxx" that, when given alone, rest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66768
--- Comment #1 from Armin Rigo ---
Update: found out that the %gs prefix is correctly present when I compile with
"gcc -O1 -fno-ivopts bug1.c -S". So ivopts might be the place to look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66768
Bug ID: 66768
Summary: __seg_fs and __seg_gs: issue when adding address space
support
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57951
--- Comment #2 from Frank Heckenbach ---
Another bug that may be related to this one (and certainly depends
on it), originally reported as Debian bug #613551:
Tested with gcc-4.1 (apparently the last version that did allow "-MD -MG"):
When usin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66588
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35514
--- Comment #1 from H.J. Lu ---
Created attachment 35912
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35912&action=edit
A patch
I am testing this patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35514
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66767
Andreas Schwab changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66767
Bug ID: 66767
Summary: [6 regression] FAIL: gcc.dg/vect/vect-align-1.c
execution test
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63930
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66739
--- Comment #4 from Andreas Schwab ---
This also breaks gcc.target/powerpc/405-nmacchw-2.c and
gcc.target/powerpc/440-nmacchw-2.c.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66757
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Component|rtl-optimiza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66757
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66718
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Sun Jul 5 12:14:41 2015
New Revision: 225434
URL: https://gcc.gnu.org/viewcvs?rev=225434&root=gcc&view=rev
Log:
PR tree-optimization/66718
* tree-vect-stmts.c (vectorizab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57859
--- Comment #3 from Mikael Pettersson ---
-ftrapv seems to be working a bit better in gcc-6: only the first test case
fails (doesn't report the overflow) at -O1/2 for both -m32/-m64, but all other
combinations of test case, -O0 vs -O1/2, and -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66458
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66718
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Sun Jul 5 12:11:57 2015
New Revision: 225433
URL: https://gcc.gnu.org/viewcvs?rev=225433&root=gcc&view=rev
Log:
PR tree-optimization/66718
* tree-vect-stmts.c (vectorizab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58493
--- Comment #4 from Mikael Pettersson ---
Checked that this works with current gcc-6/5/4.9. Can this be closed now?
55 matches
Mail list logo
