https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66964
Bug ID: 66964
Summary: Assembler error during ARM cross compile
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66964
--- Comment #1 from Hartmut Schirmer ---
Created attachment 36031
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36031&action=edit
Preprocessed file (IFCOpenings.cpp from assimp)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
Maxim Ostapenko changed:
What|Removed |Added
CC||chefmax at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66952
--- Comment #4 from Richard Biener ---
Hmm, I can't see what is wrong with the pattern. We just replace
_13 = (int) c_4;
if (_13 <= 0)
with
:
_13 = (int) c_4;
if (c_4 <= 0)
with c_4 being signed char. Something else must go wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66942
--- Comment #9 from Vittorio Zecca ---
I should have written that I tried it not only on the test case I sent
but on the whole fortran
testsuite in gcc/testsuite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #6 from Marek Polacek ---
(In reply to Maxim Ostapenko from comment #5)
> It looks like that -fsanitize=shift may introduce uninitialized variables
> itself, without other checks.
I don't see this on x86_64. But there certainly is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66964
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66916
--- Comment #3 from Richard Biener ---
It's a combination of sign-changed compare and X - Y CMP 0 to X CMP Y. Bad
is
:
_9 = end_8 - start_6;
length_10 = (size_t) _9;
if (start_6 == end_8)
and I guess good was
if (length_10 == 0)
w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62212
Paolo Carlini changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66965
Bug ID: 66965
Summary: gnat.dg/specs/addr1.ads obsolete -- failing on trunk
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66929
--- Comment #8 from Jürgen Reuter ---
Just confirmed that the fix in comment #1 works with our code and doesn't (at
least in our code) introduce any new regression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
--- Comment #14 from Manuel López-Ibáñez ---
(In reply to Jeffrey Walton from comment #13)
> #if GCC_DIAGNOSTIC_AWARE
> # pragma GCC diagnostic push
> # pragma GCC diagnostic ignored "-Wunused-value"
> # pragma GCC diagnostic ignored "-Wunused-va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870
--- Comment #9 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Wed Jul 22 10:44:16 2015
New Revision: 226059
URL: https://gcc.gnu.org/viewcvs?rev=226059&root=gcc&view=rev
Log:
gcc/ChangeLog:
2015-07-22 Charles Baylis
PR tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
--- Comment #15 from Jonathan Wakely ---
(In reply to Jeffrey Walton from comment #13)
> This issued caused Crypto++ to remove -Wall (and above) under GCC.
That seems to be throwing the baby out with the bathwater. Why not simply use
-Wall -Wn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
--- Comment #16 from Jeffrey Walton ---
(In reply to Jonathan Wakely from comment #15)
> (In reply to Jeffrey Walton from comment #13)
> > This issued caused Crypto++ to remove -Wall (and above) under GCC.
>
> That seems to be throwing the baby
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66952
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Wed Jul 22 11:31:50 2015
New Revision: 226062
URL: https://gcc.gnu.org/viewcvs?rev=226062&root=gcc&view=rev
Log:
2015-07-22 Richard Biener
PR tree-optimization/66952
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66966
Bug ID: 66966
Summary: Missing diagnostic message for ill-formed program with
anonymous enum
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66847
Jonathan Wakely changed:
What|Removed |Added
Target|=x86_64-w64-mingw32 |
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66952
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63521
--- Comment #3 from Jiong Wang ---
Author: jiwang
Date: Wed Jul 22 11:41:10 2015
New Revision: 226064
URL: https://gcc.gnu.org/viewcvs?rev=226064&root=gcc&view=rev
Log:
[AArch64] PR target/63521 Define REG_ALLOC_ORDER
2015-07-22 Jiong Wang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63521
Jiong Wang changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66966
Jonathan Wakely changed:
What|Removed |Added
Keywords||accepts-invalid
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66966
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173
Jiong Wang changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66966
--- Comment #3 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #2)
> Oh wait ... if you use -w then you are suppressing diagnostics, so you can't
> really complain that there are no diagnostics!
>
> So this seems invalid to me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66966
--- Comment #4 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #2)
> Oh wait ... if you use -w then you are suppressing diagnostics, so you can't
> really complain that there are no diagnostics!
>
> So this seems invalid to me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #7 from Marek Polacek ---
I think I have a fix now. The trick was to use unshare_expr. Testing some
more...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66966
Anders Granlund changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66964
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Target||arm
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66967
Bug ID: 66967
Summary: thread local's destructor not called if compile with
-fno-use-cxa-atexit
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #8 from Marek Polacek ---
Not really. We probably shouldn't instrument arguments of __ubsan_*
builtins...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66968
Bug ID: 66968
Summary: Incorrect template argument shown in diagnostic
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60621
julien.blanc at laposte dot net changed:
What|Removed |Added
CC||julien.blanc at laposte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60621
--- Comment #6 from julien.blanc at laposte dot net ---
Created attachment 36032
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36032&action=edit
New version of marc's code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66868
--- Comment #5 from Bill Schmidt ---
Using current trunk, I compared the 193t.optimized dumps for the original
cdrom.ii attachment and for the same attachment modified to add the debug
output statement from the end of comment 2. Other than the a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66868
--- Comment #6 from Bill Schmidt ---
Sorry, not from comment 2 on this bugzilla; comment 2 from the launchpad bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66868
--- Comment #7 from Bill Schmidt ---
I tried the same thing with a snapshot of the 5 branch I had lying around:
r225783 from 2015-07-14. I also don't see any differences in the output from
the middle end, as I would expect since this bug has sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66964
--- Comment #4 from ktkachov at gcc dot gnu.org ---
Created attachment 36033
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36033&action=edit
reduced testcase
Attaching reduced testcase.
Not the shortest, but still 100x shorter than the ori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66964
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||alalaw01 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66966
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66969
Bug ID: 66969
Summary: Internal compiler error, segmentation fault
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66868
--- Comment #8 from Bill Schmidt ---
Same experiment with r18 from 2015-04-18. Same results.
At this point I can't reproduce anything from the information given. Do you
have any local modifications that could be causing this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #9 from Marek Polacek ---
Oh silly me! This should work; Maxim, could you possibly try this patch?
--- gcc/c-family/c-ubsan.c
+++ gcc/c-family/c-ubsan.c
@@ -38,6 +38,7 @@ along with GCC; see the file COPYING3. If not see
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66966
Anders Granlund changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970
Bug ID: 66970
Summary: Add __has_builtin() macro
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #10 from Maxim Ostapenko ---
(In reply to Marek Polacek from comment #9)
> Oh silly me! This should work; Maxim, could you possibly try this patch?
Sorry, Marek, nothing changed for C++ testcase:
D.6137 = get.__delta;
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66966
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to Anders Granlund from comment #7)
> OK. Seems to work differently in Clang but I guess they don't have the same
> problem with legacy.
Changing defaults in GCC to match Clang is possible (w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66731
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #11 from Marek Polacek ---
Hmm, still can't reproduce even with vanilla trunk:
A = A.0;
D.2679 = get.__pfn;
D.2680 = (long int) D.2679;
D.2681 = D.2680 & 1;
if (D.2681 == 0) goto ; else goto ;
:
iftmp.1 = get.__pfn;
g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #59 from Mikael Morin ---
Author: mikael
Date: Wed Jul 22 15:26:52 2015
New Revision: 226074
URL: https://gcc.gnu.org/viewcvs?rev=226074&root=gcc&view=rev
Log:
Fix r225926's iso_varying_string ICE regression
PR fortran/61831
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66929
--- Comment #9 from Mikael Morin ---
Author: mikael
Date: Wed Jul 22 15:26:52 2015
New Revision: 226074
URL: https://gcc.gnu.org/viewcvs?rev=226074&root=gcc&view=rev
Log:
Fix r225926's iso_varying_string ICE regression
PR fortran/61831
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304
Ramana Radhakrishnan changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66971
Bug ID: 66971
Summary: thread_local with external linkage and constructor
cannot be compiled correctly
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66737
--- Comment #8 from Ilya Enkovich ---
Author: ienkovich
Date: Wed Jul 22 16:24:28 2015
New Revision: 226076
URL: https://gcc.gnu.org/viewcvs?rev=226076&root=gcc&view=rev
Log:
PR driver/66737
* config/i386/linux-common.h (MPX_SPEC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986
--- Comment #12 from Mikael Morin ---
(In reply to Dominique d'Humieres from comment #6)
> The test has been introduced at revision r220482,
That revision adds interesting comments:
> /* For a function with a class array result, save the resul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66971
zhykzhykzhyk at gmail dot com changed:
What|Removed |Added
Severity|critical|major
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66971
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66950
--- Comment #1 from iverbin at gcc dot gnu.org ---
Author: iverbin
Date: Wed Jul 22 17:19:31 2015
New Revision: 226080
URL: https://gcc.gnu.org/viewcvs?rev=226080&root=gcc&view=rev
Log:
2015-07-22 Maxim Blumenthal
PR libgomp/66950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870
--- Comment #13 from boger at us dot ibm.com ---
Use of the gold linker on ppc64 (BE) with static linking results in these
warnings:
/usr/local/gold/bin/ld.gold: warning:
/usr/lib/gcc/ppc64-redhat-linux/4.8.3/../../../../lib64/libc.a(malloc.o): .o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66908
--- Comment #12 from Maxim Ostapenko ---
(In reply to Marek Polacek from comment #11)
> Hmm, still can't reproduce even with vanilla trunk:
>
> A = A.0;
> D.2679 = get.__pfn;
> D.2680 = (long int) D.2679;
> D.2681 = D.2680 & 1;
> if (D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66954
--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Jul 22 18:01:33 2015
New Revision: 226081
URL: https://gcc.gnu.org/viewcvs?rev=226081&root=gcc&view=rev
Log:
libgcc/ChangeLog:
PR target/66954
* config/i386/c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66954
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66972
Bug ID: 66972
Summary: Ada.Directories doesn't recognize dangling symlinks
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66972
Pavel Zhukov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63222
--- Comment #2 from Pavel Zhukov ---
If symlink is broken Ada.Directories.Exists returns False (actually it's
because stat64 returns ENOENT in __gnat_stat).
Easy to reproduce:
mkdir 'test' && cd 'test' && touch target && ln -s target link && rm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63222
Pavel Zhukov changed:
What|Removed |Added
CC||pavel at zhukoff dot net
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66964
--- Comment #6 from alalaw01 at gcc dot gnu.org ---
Bootstrap+test in progress FYI. However, that patch *does not* fix this
failure; there must be some other route.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66973
Bug ID: 66973
Summary: Incorrect resolution of generic interface with
TYPE(C_PTR)
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66973
--- Comment #1 from Scot Breitenfeld ---
Created attachment 36036
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36036&action=edit
fortranlib_test_F03, main program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66973
--- Comment #2 from Scot Breitenfeld ---
The following sequence picks the f90 interface, when it should pick the f03
(TYPE(C_PTR)) interface.
gfortran -c H5Tff.F90
gfortran fortranlib_test_F03.f90 -o H5Tff.o
The program prints:
PRINT*,'Inside
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66973
--- Comment #3 from Scot Breitenfeld ---
(In reply to Scot Breitenfeld from comment #2)
> The following sequence picks the f90 interface, when it should pick the f03
> (TYPE(C_PTR)) interface.
>
> gfortran -c H5Tff.F90
> gfortran fortranlib_test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66973
--- Comment #4 from Scot Breitenfeld ---
The work around is instead to do:
PROGRAM main
USE H5T
IMPLICIT NONE
REAL, TARGET :: val
TYPE(C_PTR) :: f_ptr
f_ptr = C_LOC(val)
CALL pickone(f_ptr)
END PROGRAM main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66973
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66973
--- Comment #6 from Scot Breitenfeld ---
it also works if you add USE ISO_C_BINDING to the main program:
PROGRAM main
USE ISO_C_BINDING
USE H5T
IMPLICIT NONE
REAL, TARGET :: val
CALL pickone(C_LOC(val))
END PROGRAM main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66714
--- Comment #23 from cesar at gcc dot gnu.org ---
Created attachment 36037
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36037&action=edit
patch to handle different types of value exprs
This new patch handles other types besides INDIRECT_R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62536
Louis Krupp changed:
What|Removed |Added
CC||t56xjcu6dh at snkmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66974
Bug ID: 66974
Summary: -Warray-bounds false positive with -O3
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66974
DJ Delorie changed:
What|Removed |Added
CC||dj at redhat dot com
--- Comment #1 from DJ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66974
--- Comment #2 from Ganesh Ajjanagadde ---
Of course. However, the caller might ensure that order is always in the valid
range (e.g <= 3 in this case), and the callee should not have to verify this
if that is the case. The reason we do not actual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66930
--- Comment #6 from Kazumoto Kojima ---
Created attachment 36040
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36040&action=edit
.i file for gengtype.c
I've confirmed a miscompile for gengtype.c with -O1 on my 5/6
compilers. With them,
80 matches
Mail list logo
