https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
Igor Zamyatin changed:
What|Removed |Added
CC||izamyatin at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #6 from Uroš Bizjak ---
(In reply to Igor Zamyatin from comment #5)
> > Confirmed. This will affect all SSE targets.
>
> Have you managed to reproduce the issue on i686?
No, only with a crosscompiler to x86_64-apple-darwin11. The i6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #7 from Uroš Bizjak ---
The difference si that the call to f128_p3 does not expand with "use (reg:SI
bx)" tag in the Darwin case. Probably ix86_expand_call should be fixed for
TARGET_MACHO.
However, even if this will solve bootstrap,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63652
Bug ID: 63652
Summary: [AArch64_be] vzip/vuzp tests fail
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63641
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63653
Bug ID: 63653
Summary: [AArch64_be] vldX/vldX_lane tests fail
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63654
Bug ID: 63654
Summary: An explicit copy constructor should be used in the
second step of a class copy-initialization.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63205
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54521
Jonathan Wakely changed:
What|Removed |Added
CC||kariya_mitsuru at hotmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63654
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #48 from Dominique d'Humieres ---
> --- Comment #44 from Iain Sandoe ---
> (In reply to Stupachenko Evgeny from comment #43)
[...]
> there were at one point this week 4 concurrent bootstrap breaks on dariwn.
>
> this PR.
> the ipa-ic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #8 from Stupachenko Evgeny ---
(In reply to Uroš Bizjak from comment #7)
> The difference si that the call to f128_p3 does not expand with "use (reg:SI
> bx)" tag in the Darwin case. Probably ix86_expand_call should be fixed for
> TAR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #9 from Uroš Bizjak ---
(In reply to Stupachenko Evgeny from comment #8)
> (In reply to Uroš Bizjak from comment #7)
> > The difference si that the call to f128_p3 does not expand with "use (reg:SI
> > bx)" tag in the Darwin case. Pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63650
--- Comment #7 from Richard PALO ---
Further testing indicates that 'cdecl' is okay and that keeping 'regparm(0)'
causes the error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63655
Bug ID: 63655
Summary: ice using -O2 -floop-parallelize-all
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63646
Yury Gribov changed:
What|Removed |Added
CC||y.gribov at samsung dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63656
Bug ID: 63656
Summary: a-tags.adb:82:04: warning: types for unchecked
conversion have different sizes
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63638
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #14 from M Welinder ---
> 1) Your malloc is too small. It has to be sizeof (biggest member).
> So you're invoking undefined behavior.
Can you produce a specific authoritative reference for that statement?
I.e., a reference to the sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #10 from Stupachenko Evgeny ---
(In reply to Uroš Bizjak from comment #9)
> (In reply to Stupachenko Evgeny from comment #8)
> > (In reply to Uroš Bizjak from comment #7)
> > > The difference si that the call to f128_p3 does not expan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #15 from M Welinder ---
FYI, I filed a related bug for valgrind covering the problem with the
conditional jump being detected as undefined:
https://bugs.kde.org/show_bug.cgi?id=340392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610
howarth at bromo dot med.uc.edu changed:
What|Removed |Added
CC||howarth at bromo dot med
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610
--- Comment #7 from howarth at bromo dot med.uc.edu ---
I can confirm that there are many regressions (particularly in the fortran test
suite) on Yosemite due to the libtool bug which causes shared libraries to be
linked as if the target was Puma.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610
--- Comment #8 from Volker Braun ---
Another workaround is to set MACOSX_DEPLOYMENT_TARGET=10.9
Libtool-2.4.3 will have the fix, gcc (and everybody else) should just
reconfigure when its out.
http://lists.gnu.org/archive/html/libtool/2014-10/ms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #11 from Uroš Bizjak ---
(In reply to Stupachenko Evgeny from comment #10)
> Anyway, if call is not EBX dependent (say local call in Linux) the issue is
> not reproduced (like in example from PR63618).
> So the issue looks like Darwi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58644
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63657
Bug ID: 63657
Summary: [4.9 regression] -Wunused-variable: warning supressed
by virtual dtor fn
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610
--- Comment #9 from howarth at bromo dot med.uc.edu ---
Alternatively, you can just make sure you don't set MACOSX_DEPLOYMENT_TARGET in
your shell.
Also mote that gmp, mpfr and mpc also suffer from this bug and, if built on
10.10, should either
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62279
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114
--- Comment #9 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Mon Oct 27 14:04:43 2014
New Revision: 216736
URL: https://gcc.gnu.org/viewcvs?rev=216736&root=gcc&view=rev
Log:
[Vectorizer] Make REDUC_xxx_EXPR tree codes produce a scal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114
--- Comment #10 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Mon Oct 27 14:20:52 2014
New Revision: 216737
URL: https://gcc.gnu.org/viewcvs?rev=216737&root=gcc&view=rev
Log:
Add new optabs for reducing vectors to scalars
PR tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #16 from Markus Trippelsdorf ---
(In reply to M Welinder from comment #14)
> > 2) In the if statement, where you probe the different members, you
> > also invoke undefined behavior.
>
> Absolutely not! I went other that in painful d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23055
Jonathan Wakely changed:
What|Removed |Added
CC||shunichi_wakabayashi@yahoo.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63648
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63658
Bug ID: 63658
Summary: [4.8/4.9 Regression] Using class reference as template
parameter causes compilation to fail
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915
--- Comment #18 from Wilco ---
(In reply to Andrew Pinski from comment #17)
> (In reply to Wilco from comment #16)
> > (In reply to Andrew Pinski from comment #13)
> > > (In reply to Wilco from comment #9)
> > > > I committed a workaround
> > > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59799
Ramana Radhakrishnan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63658
Jonathan Wakely changed:
What|Removed |Added
Severity|major |normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #17 from M Welinder ---
You keep saying "undefined behaviour", but you keep avoiding
substantiating that claim.
Where, in the C99 standard, is the clause that makes things undefined?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63658
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #18 from M Welinder ---
The example at strict-aliasing in the gcc man page covers a different
situation: you don't get to access a double via an int.
I get it.
But the standard says that in certain circumstances you really do get
to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #19 from joseph at codesourcery dot com ---
Given
GnmExprBinary res;
GnmExpr const *expr = (GnmExpr *)&res;
the C standard does not define where the result of the conversion points;
all that's defined is that if converted direc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63576
Ilya Palachev changed:
What|Removed |Added
CC||i.palachev at samsung dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #20 from Jakub Jelinek ---
(In reply to jos...@codesourcery.com from comment #19)
> Given
>
> GnmExprBinary res;
> GnmExpr const *expr = (GnmExpr *)&res;
Let's consider if in #c11 you change:
GnmExprBinary *res = malloc (sizeo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63659
Bug ID: 63659
Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63659
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #21 from Andreas Schwab ---
This is only valid if the object is of the union type (union _GnmExpr)
(§6.5.2.3#6: "if the union object currently contains one of these structures").
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63659
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #22 from M Welinder ---
>Given
>
> GnmExprBinary res;
> GnmExpr const *expr = (GnmExpr *)&res;
>
>the C standard does not define where the result of the conversion points;
How do you read C99's Section 6.5 #7, then?
Doesn't that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63659
--- Comment #3 from Jakub Jelinek ---
Seems this is a REE bug. Before REE pass, we have:
(insn 4 27 76 6 (set (reg/v:QI 0 ax [orig:59 k ] [59])
(const_int -1 [0x])) pr63659.c:18 66 {*movqi_internal}
(expr_list:REG_EQ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62194
--- Comment #1 from Josh Triplett ---
An additional corner case: a deadfield, even one that has a default value to
allow reads of it to work rather than erroring out, must be an rvalue, so that
attempts to take the address of it fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62194
--- Comment #2 from Josh Triplett ---
One alternative implementation: if GCC supported a "property" attribute,
specifying (optional) functions to get or set the property (with compile-time
errors if attempting to get/set a property for which the
This is bug 41698. Please send a patch to gcc-patches, including the
addition of a testcase to the testsuite.
--
Joseph S. Myers
jos...@codesourcery.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #15 from joseph at codesourcery dot com ---
On Sun, 26 Oct 2014, Keith.S.Thompson at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
>
> --- Comment #14 from Keith Thompson ---
> The C standard requires th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #23 from joseph at codesourcery dot com ---
On Mon, 27 Oct 2014, jakub at gcc dot gnu.org wrote:
> Let's consider if in #c11 you change:
> GnmExprBinary *res = malloc (sizeof (GnmExprBinary));
> res->oper = op;
> return (GnmExp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63660
Bug ID: 63660
Summary: [4.8-4.9+] -Wmaybe-uninitialized false positive with
-O1 and more
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #12 from Jeffrey A. Law ---
The more I watch the %ebx PIC problems, the more this reminds me of secondary
reloads and I wonder if we defined those properly if the right things would
happen.
This kind of thing has shown up on other ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63659
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #24 from joseph at codesourcery dot com ---
On Mon, 27 Oct 2014, terra at gnome dot org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
>
> --- Comment #22 from M Welinder ---
> >Given
> >
> > GnmExprBinary res;
> > G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62194
--- Comment #3 from Josh Triplett ---
(In reply to Josh Triplett from comment #2)
> One alternative implementation: if GCC supported a "property" attribute,
> specifying (optional) functions to get or set the property (with
> compile-time errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661
Bug ID: 63661
Summary: -O2 miscompiles on OSX 10.10 Yosemite
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661
--- Comment #1 from Volker Braun ---
Created attachment 33822
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33822&action=edit
Output of gcc -v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63582
DJ Delorie changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661
--- Comment #2 from Volker Braun ---
Created attachment 33823
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33823&action=edit
Preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
Jeremy Huddleston Sequoia changed:
What|Removed |Added
CC||jeremyhu at macports dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
--- Comment #43 from Jeremy Huddleston Sequoia
---
Created attachment 33824
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33824&action=edit
gcc 4.2 based patch which handles tiny version numbers properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59799
--- Comment #11 from Michael Hudson-Doyle ---
Er yes, this was fixed before 4.9.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63658
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #49 from Igor Zamyatin ---
Testing a patch to fix asan failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63442
--- Comment #5 from Jiong Wang ---
Author: jiwang
Date: Mon Oct 27 21:58:59 2014
New Revision: 216765
URL: https://gcc.gnu.org/viewcvs?rev=216765&root=gcc&view=rev
Log:
PR63442 libgcc_cmp_return_mode not always return word_mode
gcc/
PR target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63442
Jiong Wang changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63662
Bug ID: 63662
Summary: __has_include defined but not implemented
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preproc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63662
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63662
Andrew Pinski changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63530
--- Comment #5 from carrot at gcc dot gnu.org ---
Author: carrot
Date: Tue Oct 28 00:20:13 2014
New Revision: 216770
URL: https://gcc.gnu.org/viewcvs?rev=216770&root=gcc&view=rev
Log:
PR tree-optimization/63530
tree-vect-data-refs.c (vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63663
Bug ID: 63663
Summary: [NEON] wrong value when computing the leading zero
of int16x4_t type at O2
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63662
andre.mccurdy at linaro dot org changed:
What|Removed |Added
Summary|__has_include defined but |__has_include is not
78 matches
Mail list logo
